linux-kernel - Re: [PATCH] usb: core: fix NULL dereference in usb_ifnum_to

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] [day] [month] [year] [list]

Message-Id: <20251117085058.1677226-1-dengjie03@kylinos.cn>
Date: Mon, 17 Nov 2025 16:50:58 +0800
From: Jie Deng <dengjie03@...inos.cn>
To: gregkh@...uxfoundation.org
Cc: linux-kernel@...r.kernel.org,
	linux-usb@...r.kernel.org,
	mathias.nyman@...ux.intel.com,
	sakari.ailus@...ux.intel.com,
	stern@...land.harvard.edu
Subject: Re: [PATCH] usb: core: fix NULL dereference in usb_ifnum_to_if() during device removal

Sorry for replying late.
I'm not sure why, but I didn't receive your email in my mailbox.

>> is set to NULL.At this point, outside the kernel, usb_ifnum_to_if()
>> is called through usb_set_interface(), and usb_ifnum_to_if() continues
>> to access interface[i]->altsetting[i], triggering a null pointer.
>
>I do not understand, sorry.  What do you mean by "outside the kernel"?
Sorry, I wasn't accurate in my expression. What I want to express is 
the system application program.

>
>> kernel log:
>> [ 9518.779148][ 1] [ T4650] pc : usb_ifnum_to_if+0x34/0x50
>> [ 9518.784360][ 1] [ T4650] lr : usb_hcd_alloc_bandwidth+0x260/0x348
>
>What is the [TXXX] stuff?
Superfluous information. I will delete it later.


>> --- a/drivers/usb/core/usb.c
>> +++ b/drivers/usb/core/usb.c
>> @@ -355,7 +355,7 @@ struct usb_interface *usb_ifnum_to_if(const struct usb_device *dev,
>>  	if (!config)
>>  		return NULL;
>>  	for (i = 0; i < config->desc.bNumInterfaces; i++)
>> -		if (config->interface[i]->altsetting[0]
>> +		if (config->interface[i] && config->interface[i]->altsetting[0]
>
>Are you sure this is not just papering over a race?  What prevents this
>from changing right after you check it?
>
>And what is causing this to happen now?  What commit broke this to
>require this change?
As you said, such a repair method cannot eliminate race behavior.

Next, I will attempt to eliminate this competitive factor from the 
uvc driver side.

Thanks,
Jie Deng