Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: chan: fix soft lockup in rtw89_entity_recalc_mgnt_roles()<br /> <br /> During rtw89_entity_recalc_mgnt_roles(), there is a normalizing process<br /> which will re-order the list if an entry with target pattern is found.<br /> And once one is found, should have aborted the list_for_each_entry. But,<br /> `break` just aborted the inner for-loop. The outer list_for_each_entry<br /> still continues. Normally, only the first entry will match the target<br /> pattern, and the re-ordering will change nothing, so there won&amp;#39;t be<br /> soft lockup. However, in some special cases, soft lockup would happen.<br /> <br /> Fix it by `goto fill` to break from the list_for_each_entry.<br /> <br /> The following is a sample of kernel log for this problem.<br /> <br /> watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [wpa_supplicant:2055]<br /> [...]<br /> RIP: 0010:rtw89_entity_recalc ([...] chan.c:392 chan.c:479) rtw89_core<br /> [...]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix read pointer after free in ath12k_mac_assign_vif_to_vdev()<br /> <br /> In ath12k_mac_assign_vif_to_vdev(), if arvif is created on a different<br /> radio, it gets deleted from that radio through a call to<br /> ath12k_mac_unassign_link_vif(). This action frees the arvif pointer.<br /> Subsequently, there is a check involving arvif, which will result in a<br /> read-after-free scenario.<br /> <br /> Fix this by moving this check after arvif is again assigned via call to<br /> ath12k_mac_assign_link_vif().<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wcn36xx: fix channel survey memory allocation size<br /> <br /> KASAN reported a memory allocation issue in wcn-&gt;chan_survey<br /> due to incorrect size calculation.<br /> This commit uses kcalloc to allocate memory for wcn-&gt;chan_survey,<br /> ensuring proper initialization and preventing the use of uninitialized<br /> values when there are no frames on the channel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: sch_sfq: don&amp;#39;t allow 1 packet limit<br /> <br /> The current implementation does not work correctly with a limit of<br /> 1. iproute2 actually checks for this and this patch adds the check in<br /> kernel as well.<br /> <br /> This fixes the following syzkaller reported crash:<br /> <br /> UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6<br /> index 65535 is out of range for type &amp;#39;struct sfq_head[128]&amp;#39;<br /> CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:79 [inline]<br /> dump_stack+0x125/0x19f lib/dump_stack.c:120<br /> ubsan_epilogue lib/ubsan.c:148 [inline]<br /> __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347<br /> sfq_link net/sched/sch_sfq.c:210 [inline]<br /> sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238<br /> sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500<br /> sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525<br /> qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026<br /> tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319<br /> qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026<br /> dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296<br /> netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline]<br /> dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362<br /> __dev_close_many+0x214/0x350 net/core/dev.c:1468<br /> dev_close_many+0x207/0x510 net/core/dev.c:1506<br /> unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738<br /> unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695<br /> unregister_netdevice include/linux/netdevice.h:2893 [inline]<br /> __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689<br /> tun_detach drivers/net/tun.c:705 [inline]<br /> tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640<br /> __fput+0x203/0x840 fs/file_table.c:280<br /> task_work_run+0x129/0x1b0 kernel/task_work.c:185<br /> exit_task_work include/linux/task_work.h:33 [inline]<br /> do_exit+0x5ce/0x2200 kernel/exit.c:931<br /> do_group_exit+0x144/0x310 kernel/exit.c:1046<br /> __do_sys_exit_group kernel/exit.c:1057 [inline]<br /> __se_sys_exit_group kernel/exit.c:1055 [inline]<br /> __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055<br /> do_syscall_64+0x6c/0xd0<br /> entry_SYSCALL_64_after_hwframe+0x61/0xcb<br /> RIP: 0033:0x7fe5e7b52479<br /> Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f.<br /> RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479<br /> RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000<br /> RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0<br /> R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270<br /> <br /> The crash can be also be reproduced with the following (with a tc<br /> recompiled to allow for sfq limits of 1):<br /> <br /> tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s<br /> ../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1<br /> ifconfig dummy0 up<br /> ping -I dummy0 -f -c2 -W0.1 8.8.8.8<br /> sleep 1<br /> <br /> Scenario that triggers the crash:<br /> <br /> * the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1<br /> <br /> * TBF dequeues: it peeks from SFQ which moves the packet to the<br /> gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so<br /> it schedules itself for later.<br /> <br /> * the second packet is sent and TBF tries to queues it to SFQ. qdisc<br /> qlen is now 2 and because the SFQ limit is 1 the packet is dropped<br /> by SFQ. At this point qlen is 1, and all of the SFQ slots are empty,<br /> however q-&gt;tail is not NULL.<br /> <br /> At this point, assuming no more packets are queued, when sch_dequeue<br /> runs again it will decrement the qlen for the current empty slot<br /> causing an underflow and the subsequent out of bounds access.

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