CVE-2023-54321

Description

In the Linux kernel, the following vulnerability has been resolved: driver core: fix potential null-ptr-deref in device_add() I got the following null-ptr-deref report while doing fault injection test: BUG: kernel NULL pointer dereference, address: 0000000000000058 CPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+ RIP: 0010:klist_put+0x2d/0xd0 Call Trace: <TASK> klist_remove+0xf1/0x1c0 device_release_driver_internal+0x196/0x210 bus_remove_device+0x1bd/0x240 device_add+0xd3d/0x1100 w1_add_master_device+0x476/0x490 [wire] ds2482_probe+0x303/0x3e0 [ds2482] This is how it happened: w1_alloc_dev() // The dev->driver is set to w1_master_driver. memcpy(&dev->dev, device, sizeof(struct device)); device_add() bus_add_device() dpm_sysfs_add() // It fails, calls bus_remove_device. // error path bus_remove_device() // The dev->driver is not null, but driver is not bound. __device_release_driver() klist_remove(&dev->p->knode_driver) <-- It causes null-ptr-deref. // normal path bus_probe_device() // It's not called yet. device_bind_driver() If dev->driver is set, in the error path after calling bus_add_device() in device_add(), bus_remove_device() is called, then the device will be detached from driver. But device_bind_driver() is not called yet, so it causes null-ptr-deref while access the 'knode_driver'. To fix this, set dev->driver to null in the error path before calling bus_remove_device().

Affected products

Version statuses are supplied by the assigning organization. Consult the original record for detailed ranges and platform conditions.

References

• https://git.kernel.org/stable/c/97aa8fb74bbe9aaf4ed5962a784f73b071bd16bf ↗
• https://git.kernel.org/stable/c/2c59650d078b1b3f1ea50d5f8ee9fcc537dc02d3 ↗
• https://git.kernel.org/stable/c/7cf515bf9e8c2908dc170ecf2df117162a16c9c5 ↗
• https://git.kernel.org/stable/c/17982304806c5c10924e73f7ca5556e0d7378452 ↗
• https://git.kernel.org/stable/c/f6837f34a34973ef6600c08195ed300e24e97317 ↗