Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: microchip: Fix refcount leak in mc_pcie_init_irq_domains()<br /> <br /> of_get_next_child() returns a node pointer with refcount incremented, so we<br /> should use of_node_put() on it when we don&amp;#39;t need it anymore.<br /> <br /> mc_pcie_init_irq_domains() only calls of_node_put() in the normal path,<br /> missing it in some error paths. Add missing of_node_put() to avoid<br /> refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: cp2112: prevent a buffer overflow in cp2112_xfer()<br /> <br /> Smatch warnings:<br /> drivers/hid/hid-cp2112.c:793 cp2112_xfer() error: __memcpy()<br /> &amp;#39;data-&gt;block[1]&amp;#39; too small (33 vs 255)<br /> drivers/hid/hid-cp2112.c:793 cp2112_xfer() error: __memcpy() &amp;#39;buf&amp;#39; too<br /> small (64 vs 255)<br /> <br /> The &amp;#39;read_length&amp;#39; variable is provided by &amp;#39;data-&gt;block[0]&amp;#39; which comes<br /> from user and it(read_length) can take a value between 0-255. Add an<br /> upper bound to &amp;#39;read_length&amp;#39; variable to prevent a buffer overflow in<br /> memcpy().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: mediatek-gen3: Fix refcount leak in mtk_pcie_init_irq_domains()<br /> <br /> of_get_child_by_name() returns a node pointer with refcount incremented, so<br /> we should use of_node_put() on it when we don&amp;#39;t need it anymore.<br /> <br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: host: Fix refcount leak in ehci_hcd_ppc_of_probe<br /> <br /> of_find_compatible_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: fix potential deadlock in __driver_attach<br /> <br /> In __driver_attach function, There are also AA deadlock problem,<br /> like the commit b232b02bf3c2 ("driver core: fix deadlock in<br /> __device_attach").<br /> <br /> stack like commit b232b02bf3c2 ("driver core: fix deadlock in<br /> __device_attach").<br /> list below:<br /> In __driver_attach function, The lock holding logic is as follows:<br /> ...<br /> __driver_attach<br /> if (driver_allows_async_probing(drv))<br /> device_lock(dev) // get lock dev<br /> async_schedule_dev(__driver_attach_async_helper, dev); // func<br /> async_schedule_node<br /> async_schedule_node_domain(func)<br /> entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC);<br /> /* when fail or work limit, sync to execute func, but<br /> __driver_attach_async_helper will get lock dev as<br /> will, which will lead to A-A deadlock. */<br /> if (!entry || atomic_read(&amp;entry_count) &gt; MAX_WORK) {<br /> func;<br /> else<br /> queue_work_node(node, system_unbound_wq, &amp;entry-&gt;work)<br /> device_unlock(dev)<br /> <br /> As above show, when it is allowed to do async probes, because of<br /> out of memory or work limit, async work is not be allowed, to do<br /> sync execute instead. it will lead to A-A deadlock because of<br /> __driver_attach_async_helper getting lock dev.<br /> <br /> Reproduce:<br /> and it can be reproduce by make the condition<br /> (if (!entry || atomic_read(&amp;entry_count) &gt; MAX_WORK)) untenable, like<br /> below:<br /> <br /> [ 370.785650] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables<br /> this message.<br /> [ 370.787154] task:swapper/0 state:D stack: 0 pid: 1 ppid:<br /> 0 flags:0x00004000<br /> [ 370.788865] Call Trace:<br /> [ 370.789374] <br /> [ 370.789841] __schedule+0x482/0x1050<br /> [ 370.790613] schedule+0x92/0x1a0<br /> [ 370.791290] schedule_preempt_disabled+0x2c/0x50<br /> [ 370.792256] __mutex_lock.isra.0+0x757/0xec0<br /> [ 370.793158] __mutex_lock_slowpath+0x1f/0x30<br /> [ 370.794079] mutex_lock+0x50/0x60<br /> [ 370.794795] __device_driver_lock+0x2f/0x70<br /> [ 370.795677] ? driver_probe_device+0xd0/0xd0<br /> [ 370.796576] __driver_attach_async_helper+0x1d/0xd0<br /> [ 370.797318] ? driver_probe_device+0xd0/0xd0<br /> [ 370.797957] async_schedule_node_domain+0xa5/0xc0<br /> [ 370.798652] async_schedule_node+0x19/0x30<br /> [ 370.799243] __driver_attach+0x246/0x290<br /> [ 370.799828] ? driver_allows_async_probing+0xa0/0xa0<br /> [ 370.800548] bus_for_each_dev+0x9d/0x130<br /> [ 370.801132] driver_attach+0x22/0x30<br /> [ 370.801666] bus_add_driver+0x290/0x340<br /> [ 370.802246] driver_register+0x88/0x140<br /> [ 370.802817] ? virtio_scsi_init+0x116/0x116<br /> [ 370.803425] scsi_register_driver+0x1a/0x30<br /> [ 370.804057] init_sd+0x184/0x226<br /> [ 370.804533] do_one_initcall+0x71/0x3a0<br /> [ 370.805107] kernel_init_freeable+0x39a/0x43a<br /> [ 370.805759] ? rest_init+0x150/0x150<br /> [ 370.806283] kernel_init+0x26/0x230<br /> [ 370.806799] ret_from_fork+0x1f/0x30<br /> <br /> To fix the deadlock, move the async_schedule_dev outside device_lock,<br /> as we can see, in async_schedule_node_domain, the parameter of<br /> queue_work_node is system_unbound_wq, so it can accept concurrent<br /> operations. which will also not change the code logic, and will<br /> not lead to deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kernfs: fix potential NULL dereference in __kernfs_remove<br /> <br /> When lockdep is enabled, lockdep_assert_held_write would<br /> cause potential NULL pointer dereference.<br /> <br /> Fix the following smatch warnings:<br /> <br /> fs/kernfs/dir.c:1353 __kernfs_remove() warn: variable dereferenced before check &amp;#39;kn&amp;#39; (see line 1346)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/mempolicy: fix get_nodes out of bound access<br /> <br /> When user specified more nodes than supported, get_nodes will access nmask<br /> array out of bounds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: dwc: Deallocate EPC memory on dw_pcie_ep_init() errors<br /> <br /> If dw_pcie_ep_init() fails to perform any action after the EPC memory is<br /> initialized and the MSI memory region is allocated, the latter parts won&amp;#39;t<br /> be undone thus causing a memory leak. Add a cleanup-on-error path to fix<br /> these leaks.<br /> <br /> [bhelgaas: commit log]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> intel_th: msu: Fix vmalloced buffers<br /> <br /> After commit f5ff79fddf0e ("dma-mapping: remove CONFIG_DMA_REMAP") there&amp;#39;s<br /> a chance of DMA buffer getting allocated via vmalloc(), which messes up<br /> the mmapping code:<br /> <br /> &gt; RIP: msc_mmap_fault [intel_th_msu]<br /> &gt; Call Trace:<br /> &gt; <br /> &gt; __do_fault<br /> &gt; do_fault<br /> ...<br /> <br /> Fix this by accounting for vmalloc possibility.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: sdhci-of-esdhc: Fix refcount leak in esdhc_signal_voltage_switch<br /> <br /> of_find_matching_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.<br /> of_node_put() checks null pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: sf-pdma: Add multithread support for a DMA channel<br /> <br /> When we get a DMA channel and try to use it in multiple threads it<br /> will cause oops and hanging the system.<br /> <br /> % echo 64 &gt; /sys/module/dmatest/parameters/threads_per_chan<br /> % echo 10000 &gt; /sys/module/dmatest/parameters/iterations<br /> % echo 1 &gt; /sys/module/dmatest/parameters/run<br /> [ 89.480664] Unable to handle kernel NULL pointer dereference at virtual<br /> address 00000000000000a0<br /> [ 89.488725] Oops [#1]<br /> [ 89.494708] CPU: 2 PID: 1008 Comm: dma0chan0-copy0 Not tainted<br /> 5.17.0-rc5<br /> [ 89.509385] epc : vchan_find_desc+0x32/0x46<br /> [ 89.513553] ra : sf_pdma_tx_status+0xca/0xd6<br /> <br /> This happens because of data race. Each thread rewrite channels&amp;#39;s<br /> descriptor as soon as device_prep_dma_memcpy() is called. It leads to the<br /> situation when the driver thinks that it uses right descriptor that<br /> actually is freed or substituted for other one.<br /> <br /> With current fixes a descriptor changes its value only when it has<br /> been used. A new descriptor is acquired from vc-&gt;desc_issued queue that<br /> is already filled with descriptors that are ready to be sent. Threads<br /> have no direct access to DMA channel descriptor. Now it is just possible<br /> to queue a descriptor for further processing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soundwire: revisit driver bind/unbind and callbacks<br /> <br /> In the SoundWire probe, we store a pointer from the driver ops into<br /> the &amp;#39;slave&amp;#39; structure. This can lead to kernel oopses when unbinding<br /> codec drivers, e.g. with the following sequence to remove machine<br /> driver and codec driver.<br /> <br /> /sbin/modprobe -r snd_soc_sof_sdw<br /> /sbin/modprobe -r snd_soc_rt711<br /> <br /> The full details can be found in the BugLink below, for reference the<br /> two following examples show different cases of driver ops/callbacks<br /> being invoked after the driver .remove().<br /> <br /> kernel: BUG: kernel NULL pointer dereference, address: 0000000000000150<br /> kernel: Workqueue: events cdns_update_slave_status_work [soundwire_cadence]<br /> kernel: RIP: 0010:mutex_lock+0x19/0x30<br /> kernel: Call Trace:<br /> kernel: ? sdw_handle_slave_status+0x426/0xe00 [soundwire_bus 94ff184bf398570c3f8ff7efe9e32529f532e4ae]<br /> kernel: ? newidle_balance+0x26a/0x400<br /> kernel: ? cdns_update_slave_status_work+0x1e9/0x200 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82]<br /> <br /> kernel: BUG: unable to handle page fault for address: ffffffffc07654c8<br /> kernel: Workqueue: pm pm_runtime_work<br /> kernel: RIP: 0010:sdw_bus_prep_clk_stop+0x6f/0x160 [soundwire_bus]<br /> kernel: Call Trace:<br /> kernel: <br /> kernel: sdw_cdns_clock_stop+0xb5/0x1b0 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82]<br /> kernel: intel_suspend_runtime+0x5f/0x120 [soundwire_intel aca858f7c87048d3152a4a41bb68abb9b663a1dd]<br /> kernel: ? dpm_sysfs_remove+0x60/0x60<br /> <br /> This was not detected earlier in Intel tests since the tests first<br /> remove the parent PCI device and shut down the bus. The sequence<br /> above is a corner case which keeps the bus operational but without a<br /> driver bound.<br /> <br /> While trying to solve this kernel oopses, it became clear that the<br /> existing SoundWire bus does not deal well with the unbind case.<br /> <br /> Commit 528be501b7d4a ("soundwire: sdw_slave: add probe_complete structure and new fields")<br /> added a &amp;#39;probed&amp;#39; status variable and a &amp;#39;probe_complete&amp;#39;<br /> struct completion. This status is however not reset on remove and<br /> likewise the &amp;#39;probe complete&amp;#39; is not re-initialized, so the<br /> bind/unbind/bind test cases would fail. The timeout used before the<br /> &amp;#39;update_status&amp;#39; callback was also a bad idea in hindsight, there<br /> should really be no timing assumption as to if and when a driver is<br /> bound to a device.<br /> <br /> An initial draft was based on device_lock() and device_unlock() was<br /> tested. This proved too complicated, with deadlocks created during the<br /> suspend-resume sequences, which also use the same device_lock/unlock()<br /> as the bind/unbind sequences. On a CometLake device, a bad DSDT/BIOS<br /> caused spurious resumes and the use of device_lock() caused hangs<br /> during suspend. After multiple weeks or testing and painful<br /> reverse-engineering of deadlocks on different devices, we looked for<br /> alternatives that did not interfere with the device core.<br /> <br /> A bus notifier was used successfully to keep track of DRIVER_BOUND and<br /> DRIVER_UNBIND events. This solved the bind-unbind-bind case in tests,<br /> but it can still be defeated with a theoretical corner case where the<br /> memory is freed by a .remove while the callback is in use. The<br /> notifier only helps make sure the driver callbacks are valid, but not<br /> that the memory allocated in probe remains valid while the callbacks<br /> are invoked.<br /> <br /> This patch suggests the introduction of a new &amp;#39;sdw_dev_lock&amp;#39; mutex<br /> protecting probe/remove and all driver callbacks. Since this mutex is<br /> &amp;#39;local&amp;#39; to SoundWire only, it does not interfere with existing locks<br /> and does not create deadlocks. In addition, this patch removes the<br /> &amp;#39;probe_complete&amp;#39; completion, instead we directly invoke the<br /> &amp;#39;update_status&amp;#39; from the probe routine. That removes any sort of<br /> timing dependency and a much better support for the device/driver<br /> model, the driver could be bound before the bus started, or eons after<br /> the bus started and the hardware would be properly initialized in all<br /> cases.<br /> <br /> BugLink: https://github.com/thesofproject/linux/is<br /> ---truncated---