Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> OPP: add index check to assert to avoid buffer overflow in _read_freq()<br /> <br /> Pass the freq index to the assert function to make sure<br /> we do not read a freq out of the opp-&gt;rates[] table when called<br /> from the indexed variants:<br /> dev_pm_opp_find_freq_exact_indexed() or<br /> dev_pm_opp_find_freq_ceil/floor_indexed().<br /> <br /> Add a secondary parameter to the assert function, unused<br /> for assert_single_clk() then add assert_clk_index() which<br /> will check for the clock index when called from the _indexed()<br /> find functions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()<br /> <br /> Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page()<br /> to increase test coverage.<br /> <br /> syzbot found a splat caused by hard irq blocking in<br /> ptr_ring_resize_multiple() [1]<br /> <br /> As current users of ptr_ring_resize_multiple() do not require<br /> hard irqs being masked, replace it to only block BH.<br /> <br /> Rename helpers to better reflect they are safe against BH only.<br /> <br /> - ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh()<br /> - skb_array_resize_multiple() to skb_array_resize_multiple_bh()<br /> <br /> [1]<br /> <br /> WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline]<br /> WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024<br /> RIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline]<br /> RIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780<br /> Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85<br /> RSP: 0018:ffffc9000bda6b58 EFLAGS: 00010083<br /> RAX: ffffffff8997e523 RBX: 0000000000000000 RCX: 0000000000040000<br /> RDX: ffffc9000fbd0000 RSI: 0000000000001842 RDI: 0000000000001843<br /> RBP: 0000000000000000 R08: ffffffff8997df2c R09: 1ffffd40003a000d<br /> R10: dffffc0000000000 R11: fffff940003a000e R12: ffffea0001d00040<br /> R13: ffff88802e8a4000 R14: dffffc0000000000 R15: 00000000ffffffff<br /> FS: 00007fb7aaf716c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fa15a0d4b72 CR3: 00000000561b0000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> tun_ptr_free drivers/net/tun.c:617 [inline]<br /> __ptr_ring_swap_queue include/linux/ptr_ring.h:571 [inline]<br /> ptr_ring_resize_multiple_noprof include/linux/ptr_ring.h:643 [inline]<br /> tun_queue_resize drivers/net/tun.c:3694 [inline]<br /> tun_device_event+0xaaf/0x1080 drivers/net/tun.c:3714<br /> notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93<br /> call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]<br /> call_netdevice_notifiers net/core/dev.c:2046 [inline]<br /> dev_change_tx_queue_len+0x158/0x2a0 net/core/dev.c:9024<br /> do_setlink+0xff6/0x41f0 net/core/rtnetlink.c:2923<br /> rtnl_setlink+0x40d/0x5a0 net/core/rtnetlink.c:3201<br /> rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6647<br /> netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btrtl: check for NULL in btrtl_setup_realtek()<br /> <br /> If insert an USB dongle which chip is not maintained in ic_id_table, it<br /> will hit the NULL point accessed. Add a null point check to avoid the<br /> Kernel Oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btbcm: Fix NULL deref in btbcm_get_board_name()<br /> <br /> devm_kstrdup() can return a NULL pointer on failure,but this<br /> returned value in btbcm_get_board_name() is not checked.<br /> Add NULL check in btbcm_get_board_name(), to handle kernel NULL<br /> pointer dereference error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7925: fix NULL deref check in mt7925_change_vif_links<br /> <br /> In mt7925_change_vif_links() devm_kzalloc() may return NULL but this<br /> returned value is not checked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections<br /> <br /> A report in 2019 by the syzbot fuzzer was found to be connected to two<br /> errors in the HID core associated with Resolution Multipliers. One of<br /> the errors was fixed by commit ea427a222d8b ("HID: core: Fix deadloop<br /> in hid_apply_multiplier."), but the other has not been fixed.<br /> <br /> This error arises because hid_apply_multipler() assumes that every<br /> Resolution Multiplier control is contained in a Logical Collection,<br /> i.e., there&amp;#39;s no way the routine can ever set multiplier_collection to<br /> NULL. This is in spite of the fact that the function starts with a<br /> big comment saying:<br /> <br /> * "The Resolution Multiplier control must be contained in the same<br /> * Logical Collection as the control(s) to which it is to be applied.<br /> ...<br /> * If no Logical Collection is<br /> * defined, the Resolution Multiplier is associated with all<br /> * controls in the report."<br /> * HID Usage Table, v1.12, Section 4.3.1, p30<br /> *<br /> * Thus, search from the current collection upwards until we find a<br /> * logical collection...<br /> <br /> The comment and the code overlook the possibility that none of the<br /> collections found may be a Logical Collection.<br /> <br /> The fix is to set the multiplier_collection pointer to NULL if the<br /> collection found isn&amp;#39;t a Logical Collection.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: th1520: Fix memory corruption due to incorrect array size<br /> <br /> The functions th1520_mbox_suspend_noirq and th1520_mbox_resume_noirq are<br /> intended to save and restore the interrupt mask registers in the MBOX<br /> ICU0. However, the array used to store these registers was incorrectly<br /> sized, leading to memory corruption when accessing all four registers.<br /> <br /> This commit corrects the array size to accommodate all four interrupt<br /> mask registers, preventing memory corruption during suspend and resume<br /> operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: dw: Fix use-after-free in dw_i3c_master driver due to race condition<br /> <br /> In dw_i3c_common_probe, &amp;master-&gt;hj_work is bound with<br /> dw_i3c_hj_work. And dw_i3c_master_irq_handler can call<br /> dw_i3c_master_irq_handle_ibis function to start the work.<br /> <br /> If we remove the module which will call dw_i3c_common_remove to<br /> make cleanup, it will free master-&gt;base through i3c_master_unregister<br /> while the work mentioned above will be used. The sequence of operations<br /> that may lead to a UAF bug is as follows:<br /> <br /> CPU0 CPU1<br /> <br /> | dw_i3c_hj_work<br /> dw_i3c_common_remove |<br /> i3c_master_unregister(&amp;master-&gt;base) |<br /> device_unregister(&amp;master-&gt;dev) |<br /> device_release |<br /> //free master-&gt;base |<br /> | i3c_master_do_daa(&amp;master-&gt;base)<br /> | //use master-&gt;base<br /> <br /> Fix it by ensuring that the work is canceled before proceeding with<br /> the cleanup in dw_i3c_common_remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: qcom: scm: Cleanup global &amp;#39;__scm&amp;#39; on probe failures<br /> <br /> If SCM driver fails the probe, it should not leave global &amp;#39;__scm&amp;#39;<br /> variable assigned, because external users of this driver will assume the<br /> probe finished successfully. For example TZMEM parts (&amp;#39;__scm-&gt;mempool&amp;#39;)<br /> are initialized later in the probe, but users of it (__scm_smc_call())<br /> rely on the &amp;#39;__scm&amp;#39; variable.<br /> <br /> This fixes theoretical NULL pointer exception, triggered via introducing<br /> probe deferral in SCM driver with call trace:<br /> <br /> qcom_tzmem_alloc+0x70/0x1ac (P)<br /> qcom_tzmem_alloc+0x64/0x1ac (L)<br /> qcom_scm_assign_mem+0x78/0x194<br /> qcom_rmtfs_mem_probe+0x2d4/0x38c<br /> platform_probe+0x68/0xc8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pps: Fix a use-after-free<br /> <br /> On a board running ntpd and gpsd, I&amp;#39;m seeing a consistent use-after-free<br /> in sys_exit() from gpsd when rebooting:<br /> <br /> pps pps1: removed<br /> ------------[ cut here ]------------<br /> kobject: &amp;#39;(null)&amp;#39; (00000000db4bec24): is not initialized, yet kobject_put() is being called.<br /> WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150<br /> CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1<br /> Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : kobject_put+0x120/0x150<br /> lr : kobject_put+0x120/0x150<br /> sp : ffffffc0803d3ae0<br /> x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001<br /> x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440<br /> x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600<br /> x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20<br /> x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000<br /> x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000<br /> x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000<br /> Call trace:<br /> kobject_put+0x120/0x150<br /> cdev_put+0x20/0x3c<br /> __fput+0x2c4/0x2d8<br /> ____fput+0x1c/0x38<br /> task_work_run+0x70/0xfc<br /> do_exit+0x2a0/0x924<br /> do_group_exit+0x34/0x90<br /> get_signal+0x7fc/0x8c0<br /> do_signal+0x128/0x13b4<br /> do_notify_resume+0xdc/0x160<br /> el0_svc+0xd4/0xf8<br /> el0t_64_sync_handler+0x140/0x14c<br /> el0t_64_sync+0x190/0x194<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> ...followed by more symptoms of corruption, with similar stacks:<br /> <br /> refcount_t: underflow; use-after-free.<br /> kernel BUG at lib/list_debug.c:62!<br /> Kernel panic - not syncing: Oops - BUG: Fatal exception<br /> <br /> This happens because pps_device_destruct() frees the pps_device with the<br /> embedded cdev immediately after calling cdev_del(), but, as the comment<br /> above cdev_del() notes, fops for previously opened cdevs are still<br /> callable even after cdev_del() returns. I think this bug has always<br /> been there: I can&amp;#39;t explain why it suddenly started happening every time<br /> I reboot this particular board.<br /> <br /> In commit d953e0e837e6 ("pps: Fix a use-after free bug when<br /> unregistering a source."), George Spelvin suggested removing the<br /> embedded cdev. That seems like the simplest way to fix this, so I&amp;#39;ve<br /> implemented his suggestion, using __register_chrdev() with pps_idr<br /> becoming the source of truth for which minor corresponds to which<br /> device.<br /> <br /> But now that pps_idr defines userspace visibility instead of cdev_add(),<br /> we need to be sure the pps-&gt;dev refcount can&amp;#39;t reach zero while<br /> userspace can still find it again. So, the idr_remove() call moves to<br /> pps_unregister_cdev(), and pps_idr now holds a reference to pps-&gt;dev.<br /> <br /> pps_core: source serial1 got cdev (251:1)<br /> <br /> pps pps1: removed<br /> pps_core: unregistering pps1<br /> pps_core: deallocating pps1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: uvcvideo: Fix double free in error path<br /> <br /> If the uvc_status_init() function fails to allocate the int_urb, it will<br /> free the dev-&gt;status pointer but doesn&amp;#39;t reset the pointer to NULL. This<br /> results in the kfree() call in uvc_status_cleanup() trying to<br /> double-free the memory. Fix it by resetting the dev-&gt;status pointer to<br /> NULL after freeing it.<br /> <br /> Reviewed by: Ricardo Ribalda

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci: Fix NULL pointer dereference on certain command aborts<br /> <br /> If a command is queued to the final usable TRB of a ring segment, the<br /> enqueue pointer is advanced to the subsequent link TRB and no further.<br /> If the command is later aborted, when the abort completion is handled<br /> the dequeue pointer is advanced to the first TRB of the next segment.<br /> <br /> If no further commands are queued, xhci_handle_stopped_cmd_ring() sees<br /> the ring pointers unequal and assumes that there is a pending command,<br /> so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.<br /> <br /> Don&amp;#39;t attempt timer setup if cur_cmd is NULL. The subsequent doorbell<br /> ring likely is unnecessary too, but it&amp;#39;s harmless. Leave it alone.<br /> <br /> This is probably Bug 219532, but no confirmation has been received.<br /> <br /> The issue has been independently reproduced and confirmed fixed using<br /> a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.<br /> Everything continued working normally after several prevented crashes.