CVE-2022-48838

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: Fix use-after-free bug by not setting udc->dev.driver

The syzbot fuzzer found a use-after-free bug:

BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320 Read of size 8 at addr ffff88802b934098 by task udevd/3689

CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 dev_uevent+0x712/0x780 drivers/base/core.c:2320 uevent_show+0x1b8/0x380 drivers/base/core.c:2391 dev_attr_show+0x4b/0x90 drivers/base/core.c:2094

Although the bug manifested in the driver core, the real cause was a race with the gadget core. dev_uevent() does:

if (dev->driver)
	add_uevent_var(env, DRIVER=%s, dev->driver->name);

and between the test and the dereference of dev->driver, the gadget core sets dev->driver to NULL.

The race wouldnt occur if the gadget core registered its devices on a real bus, using the standard synchronization techniques of the driver core. However, its not necessary to make such a large change in order to fix this bug; all we need to do is make sure that udc->dev.driver is always NULL.

In fact, there is no reason for udc->dev.driver ever to be set to anything, let alone to the value it currently gets: the address of the gadgets driver. After all, a gadget driver only knows how to manage a gadget, not how to manage a UDC.

This patch simply removes the statements in the gadget core that touch udc->dev.driver.

Weakness

Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.

Affected Software

Extended Description

The use of previously-freed memory can have any number of adverse consequences, ranging from the corruption of valid data to the execution of arbitrary code, depending on the instantiation and timing of the flaw. The simplest way data corruption may occur involves the system’s reuse of the freed memory. Use-after-free errors have two common and sometimes overlapping causes:

In this scenario, the memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process. If the newly allocated data happens to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.

Potential Mitigations

References

• https://git.kernel.org/stable/c/00bdd9bf1ac6d401ad926d3d8df41b9f1399f646
• https://git.kernel.org/stable/c/16b1941eac2bd499f065a6739a40ce0011a3d740
• https://git.kernel.org/stable/c/2015c23610cd0efadaeca4d3a8d1dae9a45aa35a
• https://git.kernel.org/stable/c/2282a6eb6d4e118e294e43dcc421e0e0fe4040b5
• https://git.kernel.org/stable/c/27d64436984fb8835a8b7e95993193cc478b162e
• https://git.kernel.org/stable/c/4325124dde6726267813c736fee61226f1d38f0b
• https://git.kernel.org/stable/c/609a7119bffe3ddd7c93f2fa65be8917e02a0b7e
• https://git.kernel.org/stable/c/e2d3a7009e505e120805f449c832942660f3f7f3