linux-kernel - Re: [PATCH] usb: xhci: fix missing null termination after copy_from

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 for Android: free password hash cracker in your pocket

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

Message-ID: <2026011731-reabsorb-obtuse-8d2d@gregkh>
Date: Sat, 17 Jan 2026 13:17:11 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: David Laight <david.laight.linux@...il.com>
Cc: Weigang He <geoffreyhe2@...il.com>, mathias.nyman@...el.com,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org
Subject: Re: [PATCH] usb: xhci: fix missing null termination after
 copy_from_user()

On Sat, Jan 17, 2026 at 12:06:32PM +0000, David Laight wrote:
> On Sat, 17 Jan 2026 10:58:41 +0100
> Greg KH <gregkh@...uxfoundation.org> wrote:
> 
> > On Sat, Jan 17, 2026 at 09:46:31AM +0000, Weigang He wrote:
> > > The buffer 'buf' is filled by copy_from_user() but is not properly
> > > null-terminated before being used with strncmp(). If userspace provides
> > > fewer than 10 bytes, strncmp() may read beyond the copied data into
> > > uninitialized stack memory.  
> > 
> > But that's fine, it will not match the check, and so it will stop when
> > told, so no overflow happens anywhere.
> 
> That's not entirely true.
> If the user passes "complianc" (without a '\0') and the on-stack buf[9]
> happens to be 'e' then the test will succeed rather than fail.

Ok, fair enough, but you are root doing this so you can do much worse
things to the system than this :)

> But the only thing that will get upset is KASAN.

Agreed.

> More 'interestingly':
> - why is it min_t() not min(), everything is size_t.
> - why sizeof(buf) - 1, reading into the last byte won't matter.
> - why buf[32] not buf[10], even [16] would be plenty for 'future expansion'.

It's debugfs, who are we to judge :)

greg k-h