Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci_plat_remove: avoid NULL dereference<br /> <br /> Since commit 4736ebd7fcaff1eb8481c140ba494962847d6e0a ("usb: host:<br /> xhci-plat: omit shared hcd if either root hub has no ports")<br /> xhci-&gt;shared_hcd can be NULL, which causes the following Oops<br /> on reboot:<br /> <br /> [ 710.124450] systemd-shutdown[1]: Rebooting.<br /> [ 710.298861] xhci-hcd xhci-hcd.2.auto: remove, state 4<br /> [ 710.304217] usb usb3: USB disconnect, device number 1<br /> [ 710.317441] xhci-hcd xhci-hcd.2.auto: USB bus 3 deregistered<br /> [ 710.323280] xhci-hcd xhci-hcd.2.auto: remove, state 1<br /> [ 710.328401] usb usb2: USB disconnect, device number 1<br /> [ 710.333515] usb 2-3: USB disconnect, device number 2<br /> [ 710.467649] xhci-hcd xhci-hcd.2.auto: USB bus 2 deregistered<br /> [ 710.475450] Unable to handle kernel NULL pointer dereference at virtual address 00000000000003b8<br /> [ 710.484425] Mem abort info:<br /> [ 710.487265] ESR = 0x0000000096000004<br /> [ 710.491060] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 710.496427] SET = 0, FnV = 0<br /> [ 710.499525] EA = 0, S1PTW = 0<br /> [ 710.502716] FSC = 0x04: level 0 translation fault<br /> [ 710.507648] Data abort info:<br /> [ 710.510577] ISV = 0, ISS = 0x00000004<br /> [ 710.514462] CM = 0, WnR = 0<br /> [ 710.517480] user pgtable: 4k pages, 48-bit VAs, pgdp=00000008b0050000<br /> [ 710.523976] [00000000000003b8] pgd=0000000000000000, p4d=0000000000000000<br /> [ 710.530961] Internal error: Oops: 96000004 [#1] PREEMPT SMP<br /> [ 710.536551] Modules linked in: rfkill input_leds snd_soc_simple_card snd_soc_simple_card_utils snd_soc_nau8822 designware_i2s snd_soc_core dw_hdmi_ahb_audio snd_pcm_dmaengine arm_ccn panfrost ac97_bus gpu_sched snd_pcm at24 fuse configfs sdhci_of_dwcmshc sdhci_pltfm sdhci nvme led_class mmc_core nvme_core bt1_pvt polynomial tp_serio snd_seq_midi snd_seq_midi_event snd_seq snd_timer snd_rawmidi snd_seq_device snd soundcore efivarfs ipv6<br /> [ 710.575286] CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted 5.19.0-rc7-00043-gfd8619f4fd54 #1<br /> [ 710.583822] Hardware name: T-Platforms TF307-MB/BM1BM1-A, BIOS 5.6 07/06/2022<br /> [ 710.590972] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 710.597949] pc : usb_remove_hcd+0x34/0x1e4<br /> [ 710.602067] lr : xhci_plat_remove+0x74/0x140<br /> [ 710.606351] sp : ffff800009f3b7c0<br /> [ 710.609674] x29: ffff800009f3b7c0 x28: ffff000800960040 x27: 0000000000000000<br /> [ 710.616833] x26: ffff800008dc22a0 x25: 0000000000000000 x24: 0000000000000000<br /> [ 710.623992] x23: 0000000000000000 x22: ffff000805465810 x21: ffff000805465800<br /> [ 710.631149] x20: ffff000800f80000 x19: 0000000000000000 x18: ffffffffffffffff<br /> [ 710.638307] x17: ffff000805096000 x16: ffff00080633b800 x15: ffff000806537a1c<br /> [ 710.645465] x14: 0000000000000001 x13: 0000000000000000 x12: ffff00080378d6f0<br /> [ 710.652621] x11: ffff00080041a900 x10: ffff800009b204e8 x9 : ffff8000088abaa4<br /> [ 710.659779] x8 : ffff000800960040 x7 : ffff800009409000 x6 : 0000000000000001<br /> [ 710.666936] x5 : ffff800009241000 x4 : ffff800009241440 x3 : 0000000000000000<br /> [ 710.674094] x2 : ffff000800960040 x1 : ffff000800960040 x0 : 0000000000000000<br /> [ 710.681251] Call trace:<br /> [ 710.683704] usb_remove_hcd+0x34/0x1e4<br /> [ 710.687467] xhci_plat_remove+0x74/0x140<br /> [ 710.691400] platform_remove+0x34/0x70<br /> [ 710.695165] device_remove+0x54/0x90<br /> [ 710.698753] device_release_driver_internal+0x200/0x270<br /> [ 710.703992] device_release_driver+0x24/0x30<br /> [ 710.708273] bus_remove_device+0xe0/0x16c<br /> [ 710.712293] device_del+0x178/0x390<br /> [ 710.715797] platform_device_del.part.0+0x24/0x90<br /> [ 710.720514] platform_device_unregister+0x30/0x50<br /> [ 710.725232] dwc3_host_exit+0x20/0x30<br /> [ 710.728907] dwc3_remove+0x174/0x1b0<br /> [ 710.732494] platform_remove+0x34/0x70<br /> [ 710.736254] device_remove+0x54/0x90<br /> [ 710.739840] device_release_driver_internal+0x200/0x270<br /> [ 710.745078] device_release_driver+0x24/0x30<br /> [ 710.749359] bus_remove_device+0xe0/0x16c<br /> [ 710.753380] device_del+0x178/0x390<br /> [ 710.756881] platform_device_del.part<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: cdns3: change place of &amp;#39;priv_ep&amp;#39; assignment in cdns3_gadget_ep_dequeue(), cdns3_gadget_ep_enable()<br /> <br /> If &amp;#39;ep&amp;#39; is NULL, result of ep_to_cdns3_ep(ep) is invalid pointer<br /> and its dereference with priv_ep-&gt;cdns3_dev may cause panic.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.