diff mbox series

[2/3] USB: cdc-acm: fix unprivileged TIOCCSERIAL

Message ID 20210407102845.32720-3-johan@kernel.org
State Superseded
Headers show
Series USB: cdc-acm: TIOCSSERIAL fixes | expand

Commit Message

Johan Hovold April 7, 2021, 10:28 a.m. UTC
TIOCSSERIAL is a horrid, underspecified, legacy interface which for most
serial devices is only useful for setting the close_delay and
closing_wait parameters.

A non-privileged user has only ever been able to set the since long
deprecated ASYNC_SPD flags and trying to change any other *supported*
feature should result in -EPERM being returned. Setting the current
values for any supported features should return success.

Fix the cdc-acm implementation which instead indicated that the
TIOCSSERIAL ioctl was not even implemented when a non-privileged user
set the current values.

Fixes: ba2d8ce9db0a ("cdc-acm: implement TIOCSSERIAL to avoid blocking close(2)")
Signed-off-by: Johan Hovold <johan@kernel.org>
---
 drivers/usb/class/cdc-acm.c | 2 --
 1 file changed, 2 deletions(-)

Comments

Oliver Neukum April 8, 2021, 7:48 a.m. UTC | #1
Am Mittwoch, den 07.04.2021, 12:28 +0200 schrieb Johan Hovold:
> TIOCSSERIAL is a horrid, underspecified, legacy interface which for most

> serial devices is only useful for setting the close_delay and

> closing_wait parameters.

> 

> A non-privileged user has only ever been able to set the since long

> deprecated ASYNC_SPD flags and trying to change any other *supported*

> feature should result in -EPERM being returned. Setting the current

> values for any supported features should return success.

> 

> Fix the cdc-acm implementation which instead indicated that the

> TIOCSSERIAL ioctl was not even implemented when a non-privileged user

> set the current values.


Hi,

the idea here was that you are setting something else, if you are
not changing a parameter that can be changed. That conclusion is
dubious, but at the same time, this implementation can change
only these two parameters. So can the test really be dropped
as opposed to be modified?

	Regards
		Oliver
Johan Hovold April 8, 2021, 9:42 a.m. UTC | #2
On Thu, Apr 08, 2021 at 09:48:38AM +0200, Oliver Neukum wrote:
> Am Mittwoch, den 07.04.2021, 12:28 +0200 schrieb Johan Hovold:

> > TIOCSSERIAL is a horrid, underspecified, legacy interface which for most

> > serial devices is only useful for setting the close_delay and

> > closing_wait parameters.

> > 

> > A non-privileged user has only ever been able to set the since long

> > deprecated ASYNC_SPD flags and trying to change any other *supported*

> > feature should result in -EPERM being returned. Setting the current

> > values for any supported features should return success.

> > 

> > Fix the cdc-acm implementation which instead indicated that the

> > TIOCSSERIAL ioctl was not even implemented when a non-privileged user

> > set the current values.

> 

> Hi,

> 

> the idea here was that you are setting something else, if you are

> not changing a parameter that can be changed. That conclusion is

> dubious, but at the same time, this implementation can change

> only these two parameters. So can the test really be dropped

> as opposed to be modified?


The de-facto standard for how to handle change requests for
non-supported features (e.g. changing the I/O port or IRQ) is to simply
ignore them and return 0.

For most (non-legacy) serial devices the only relevant parameters are
close_delay and closing_wait. And as we need to return -EPERM when a
non-privileged user tries to change these, we cannot drop the test.

(And returning -EOPNOTSUPP was never correct as the ioctl is indeed
supported.)

Johan
Oliver Neukum April 8, 2021, 11:35 a.m. UTC | #3
Am Donnerstag, den 08.04.2021, 11:42 +0200 schrieb Johan Hovold:
> On Thu, Apr 08, 2021 at 09:48:38AM +0200, Oliver Neukum wrote:

> > Am Mittwoch, den 07.04.2021, 12:28 +0200 schrieb Johan Hovold:

> > > TIOCSSERIAL is a horrid, underspecified, legacy interface which for most

> > > serial devices is only useful for setting the close_delay and

> > > closing_wait parameters.

> > > 

> > > A non-privileged user has only ever been able to set the since long

> > > deprecated ASYNC_SPD flags and trying to change any other *supported*

> > > feature should result in -EPERM being returned. Setting the current

> > > values for any supported features should return success.

> > > 

> > > Fix the cdc-acm implementation which instead indicated that the

> > > TIOCSSERIAL ioctl was not even implemented when a non-privileged user

> > > set the current values.

> > 

> > Hi,

> > 

> > the idea here was that you are setting something else, if you are

> > not changing a parameter that can be changed. That conclusion is

> > dubious, but at the same time, this implementation can change

> > only these two parameters. So can the test really be dropped

> > as opposed to be modified?

> 

> The de-facto standard for how to handle change requests for

> non-supported features (e.g. changing the I/O port or IRQ) is to simply

> ignore them and return 0.

> 

> For most (non-legacy) serial devices the only relevant parameters are

> close_delay and closing_wait. And as we need to return -EPERM when a

> non-privileged user tries to change these, we cannot drop the test.

> 

> (And returning -EOPNOTSUPP was never correct as the ioctl is indeed

> supported.)


OK, thanks for clarification. Yes the fix makes sense.

	Regards
		Oliver
diff mbox series

Patch

diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 96e221803fa6..43e31dad4831 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -955,8 +955,6 @@  static int set_serial_info(struct tty_struct *tty, struct serial_struct *ss)
 		if ((close_delay != acm->port.close_delay) ||
 		    (closing_wait != acm->port.closing_wait))
 			retval = -EPERM;
-		else
-			retval = -EOPNOTSUPP;
 	} else {
 		acm->port.close_delay  = close_delay;
 		acm->port.closing_wait = closing_wait;