linux-kernel - Re: [PATCH] usb: gadget: f_uac2: fix non-newline-terminated function name

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zo6M2RntMo6Qnx3B-jkeeping@inmusicbrands.com>
Date: Wed, 10 Jul 2024 14:30:01 +0100
From: John Keeping <jkeeping@...usicbrands.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: John Keeping <jkeeping@...usicbrands.com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: gadget: f_uac2: fix non-newline-terminated function
 name

On Wed, Jul 10, 2024 at 01:53:22PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jul 08, 2024 at 03:25:53PM +0100, John Keeping wrote:
> > Most writes to configfs handle an optional newline, but do not require
> > it.  By using the number of bytes written as the limit for scnprintf()
> > it is guaranteed that the final character in the buffer will be
> > overwritten.
> > 
> > This is expected if it is a newline but is undesirable when a string is
> > written "as-is" (as libusbgx does, for example).
> 
> So we are changing kernel functionality because a userspace program does
> not work?  Why not fix the userspace program?

This file behaves differently from every other sysfs/debugfs/configfs
file AFAICT.  In most places the behaviour of the following two commands
is equivalent:

	$ echo foo >file

	$ printf foo >file

But for this function_name the result is that the final character is
dropped unconditionally, so the name reported in the USB descriptors
will be "fo" in the second case.

> > Update the store function to strip an optional newline, matching the
> > behaviour of usb_string_copy().
> 
> This changes the behaviour of a lot of configfs files right?  What will
> break if this happens?

No, this is just one file in f_uac2.

I can't see any scenario where a newline in a USB string descriptor
makes sense so it's unlikely to break any existing use cases.

This brings the audio function name more in line with other string
descriptors for the device manufacturer/product or configuration name
which use usb_string_copy() and strip a trailing newline if it's
present.

Regards,
John