Vulnerabilities

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---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> intel_th: Fix a resource leak in an error handling path<br /> <br /> If an error occurs after calling &amp;#39;pci_alloc_irq_vectors()&amp;#39;,<br /> &amp;#39;pci_free_irq_vectors()&amp;#39; must be called as already done in the remove<br /> function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memstick/ms_block: Fix a memory leak<br /> <br /> &amp;#39;erased_blocks_bitmap&amp;#39; is never freed. As it is allocated at the same time<br /> as &amp;#39;used_blocks_bitmap&amp;#39;, it is likely that it should be freed also at the<br /> same time.<br /> <br /> Add the corresponding bitmap_free() in msb_data_clear().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: aspeed-vhub: Fix refcount leak bug in ast_vhub_init_desc()<br /> <br /> We should call of_node_put() for the reference returned by<br /> of_get_child_by_name() which has increased the refcount.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/qedr: Fix potential memory leak in __qedr_alloc_mr()<br /> <br /> __qedr_alloc_mr() allocates a memory chunk for "mr-&gt;info.pbl_table" with<br /> init_mr_info(). When rdma_alloc_tid() and rdma_register_tid() fail, "mr"<br /> is released while "mr-&gt;info.pbl_table" is not released, which will lead<br /> to a memory leak.<br /> <br /> We should release the "mr-&gt;info.pbl_table" with qedr_free_pbl() when error<br /> occurs to fix the memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Fix a window for use-after-free<br /> <br /> During a destroy CQ an interrupt may cause processing of a CQE after CQ<br /> resources are freed by irdma_cq_free_rsrc(). Fix this by moving the call<br /> to irdma_cq_free_rsrc() after the irdma_sc_cleanup_ceqes(), which is<br /> called under the cq_lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/siw: Fix duplicated reported IW_CM_EVENT_CONNECT_REPLY event<br /> <br /> If siw_recv_mpa_rr returns -EAGAIN, it means that the MPA reply hasn&amp;#39;t<br /> been received completely, and should not report IW_CM_EVENT_CONNECT_REPLY<br /> in this case. This may trigger a call trace in iw_cm. A simple way to<br /> trigger this:<br /> server: ib_send_lat<br /> client: ib_send_lat -R <br /> <br /> The call trace looks like this:<br /> <br /> kernel BUG at drivers/infiniband/core/iwcm.c:894!<br /> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> <br /> Workqueue: iw_cm_wq cm_work_handler [iw_cm]<br /> Call Trace:<br /> <br /> cm_work_handler+0x1dd/0x370 [iw_cm]<br /> process_one_work+0x1e2/0x3b0<br /> worker_thread+0x49/0x2e0<br /> ? rescuer_thread+0x370/0x370<br /> kthread+0xe5/0x110<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x1f/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix BUG: KASAN: null-ptr-deref in rxe_qp_do_cleanup<br /> <br /> The function rxe_create_qp calls rxe_qp_from_init. If some error<br /> occurs, the error handler of function rxe_qp_from_init will set<br /> both scq and rcq to NULL.<br /> <br /> Then rxe_create_qp calls rxe_put to handle qp. In the end,<br /> rxe_qp_do_cleanup is called by rxe_put. rxe_qp_do_cleanup directly<br /> accesses scq and rcq before checking them. This will cause<br /> null-ptr-deref error.<br /> <br /> The call graph is as below:<br /> <br /> rxe_create_qp {<br /> ...<br /> rxe_qp_from_init {<br /> ...<br /> err1:<br /> ...<br /> qp-&gt;rcq = NULL; scq = NULL; scq-&gt;num_wq); rcq-&gt;num_wq);

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hfi1: fix potential memory leak in setup_base_ctxt()<br /> <br /> setup_base_ctxt() allocates a memory chunk for uctxt-&gt;groups with<br /> hfi1_alloc_ctxt_rcv_groups(). When init_user_ctxt() fails, uctxt-&gt;groups<br /> is not released, which will lead to a memory leak.<br /> <br /> We should release the uctxt-&gt;groups with hfi1_free_ctxt_rcv_groups()<br /> when init_user_ctxt() fails.