Vulnerabilities

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 /> 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 /> powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW<br /> <br /> Power Hypervisor can possibily allocate MMIO window intersecting with<br /> Dynamic DMA Window (DDW) range, which is over 32-bit addressing.<br /> <br /> These MMIO pages needs to be marked as reserved so that IOMMU doesn&amp;#39;t map<br /> DMA buffers in this range.<br /> <br /> The current code is not marking these pages correctly which is resulting<br /> in LPAR to OOPS while booting. The stack is at below<br /> <br /> BUG: Unable to handle kernel data access on read at 0xc00800005cd40000<br /> Faulting instruction address: 0xc00000000005cdac<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries<br /> Modules linked in: af_packet rfkill ibmveth(X) lpfc(+) nvmet_fc nvmet nvme_keyring crct10dif_vpmsum nvme_fc nvme_fabrics nvme_core be2net(+) nvme_auth rtc_generic nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse configfs ip_tables x_tables xfs libcrc32c dm_service_time ibmvfc(X) scsi_transport_fc vmx_crypto gf128mul crc32c_vpmsum dm_mirror dm_region_hash dm_log dm_multipath dm_mod sd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua t10_pi crc64_rocksoft_generic crc64_rocksoft sg crc64 scsi_mod<br /> Supported: Yes, External<br /> CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b<br /> Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950_149) hv:phyp pSeries<br /> Workqueue: events work_for_cpu_fn<br /> NIP: c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000<br /> REGS: c00001400c9ff770 TRAP: 0300 Not tainted (6.4.0-150600.23.14-default)<br /> MSR: 800000000280b033 CR: 24228448 XER: 00000001<br /> CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0<br /> GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800<br /> GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000<br /> GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff<br /> GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000<br /> GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800<br /> GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b<br /> GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8<br /> GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800<br /> NIP [c00000000005cdac] iommu_table_reserve_pages+0xac/0x100<br /> LR [c00000000005e830] iommu_init_table+0x80/0x1e0<br /> Call Trace:<br /> [c00001400c9ffa10] [c00000000005e810] iommu_init_table+0x60/0x1e0 (unreliable)<br /> [c00001400c9ffa90] [c00000000010356c] iommu_bypass_supported_pSeriesLP+0x9cc/0xe40<br /> [c00001400c9ffc30] [c00000000005c300] dma_iommu_dma_supported+0xf0/0x230<br /> [c00001400c9ffcb0] [c00000000024b0c4] dma_supported+0x44/0x90<br /> [c00001400c9ffcd0] [c00000000024b14c] dma_set_mask+0x3c/0x80<br /> [c00001400c9ffd00] [c0080000555b715c] be_probe+0xc4/0xb90 [be2net]<br /> [c00001400c9ffdc0] [c000000000986f3c] local_pci_probe+0x6c/0x110<br /> [c00001400c9ffe40] [c000000000188f28] work_for_cpu_fn+0x38/0x60<br /> [c00001400c9ffe70] [c00000000018e454] process_one_work+0x314/0x620<br /> [c00001400c9fff10] [c00000000018f280] worker_thread+0x2b0/0x620<br /> [c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150<br /> [c00001400c9fffe0] [c00000000000ded8] start_kernel_thread+0x14/0x18<br /> <br /> There are 2 issues in the code<br /> <br /> 1. The index is "int" while the address is "unsigned long". This results in<br /> negative value when setting the bitmap.<br /> <br /> 2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit<br /> address). MMIO address needs to be page shifted as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7925: fix off by one in mt7925_load_clc()<br /> <br /> This comparison should be &gt;= instead of &gt; to prevent an out of bounds<br /> read and write.

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.