Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: consolidate suboption status<br /> <br /> MPTCP maintains the received sub-options status is the bitmask carrying<br /> the received suboptions and in several bitfields carrying per suboption<br /> additional info.<br /> <br /> Zeroing the bitmask before parsing is not enough to ensure a consistent<br /> status, and the MPTCP code has to additionally clear some bitfiled<br /> depending on the actually parsed suboption.<br /> <br /> The above schema is fragile, and syzbot managed to trigger a path where<br /> a relevant bitfield is not cleared/initialized:<br /> <br /> BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline]<br /> BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline]<br /> BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline]<br /> BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209<br /> __mptcp_expand_seq net/mptcp/options.c:1030 [inline]<br /> mptcp_expand_seq net/mptcp/protocol.h:864 [inline]<br /> ack_update_msk net/mptcp/options.c:1060 [inline]<br /> mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209<br /> tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233<br /> tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264<br /> tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916<br /> tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351<br /> ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205<br /> ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254<br /> dst_input include/net/dst.h:460 [inline]<br /> ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567<br /> __netif_receive_skb_one_core net/core/dev.c:5704 [inline]<br /> __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817<br /> process_backlog+0x4ad/0xa50 net/core/dev.c:6149<br /> __napi_poll+0xe7/0x980 net/core/dev.c:6902<br /> napi_poll net/core/dev.c:6971 [inline]<br /> net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093<br /> handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561<br /> __do_softirq+0x14/0x1a kernel/softirq.c:595<br /> do_softirq+0x9a/0x100 kernel/softirq.c:462<br /> __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389<br /> local_bh_enable include/linux/bottom_half.h:33 [inline]<br /> rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]<br /> __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493<br /> dev_queue_xmit include/linux/netdevice.h:3168 [inline]<br /> neigh_hh_output include/net/neighbour.h:523 [inline]<br /> neigh_output include/net/neighbour.h:537 [inline]<br /> ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236<br /> __ip_finish_output+0x287/0x810<br /> ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324<br /> NF_HOOK_COND include/linux/netfilter.h:303 [inline]<br /> ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434<br /> dst_output include/net/dst.h:450 [inline]<br /> ip_local_out net/ipv4/ip_output.c:130 [inline]<br /> __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536<br /> ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550<br /> __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468<br /> tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline]<br /> tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829<br /> __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012<br /> tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618<br /> __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130<br /> __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496<br /> mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550<br /> mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889<br /> mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline]<br /> mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline]<br /> mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline]<br /> mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750<br /> genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]<br /> <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: rtl8150: enable basic endpoint checking<br /> <br /> Syzkaller reports [1] encountering a common issue of utilizing a wrong<br /> usb endpoint type during URB submitting stage. This, in turn, triggers<br /> a warning shown below.<br /> <br /> For now, enable simple endpoint checking (specifically, bulk and<br /> interrupt eps, testing control one is not essential) to mitigate<br /> the issue with a view to do other related cosmetic changes later,<br /> if they are necessary.<br /> <br /> [1] Syzkaller report:<br /> usb 1-1: BOGUS urb xfer, pipe 3 != type 1<br /> WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv&gt;<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617&gt;<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024<br /> RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503<br /> Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8&gt;<br /> RSP: 0018:ffffc9000441f740 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9<br /> RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001<br /> RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001<br /> R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c<br /> FS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733<br /> __dev_open+0x2d4/0x4e0 net/core/dev.c:1474<br /> __dev_change_flags+0x561/0x720 net/core/dev.c:8838<br /> dev_change_flags+0x8f/0x160 net/core/dev.c:8910<br /> devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177<br /> inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003<br /> sock_do_ioctl+0x116/0x280 net/socket.c:1222<br /> sock_ioctl+0x22e/0x6c0 net/socket.c:1341<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl fs/ioctl.c:893 [inline]<br /> __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fc04ef73d49<br /> ...<br /> <br /> This change has not been tested on real hardware.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rose: prevent integer overflows in rose_setsockopt()<br /> <br /> In case of possible unpredictably large arguments passed to<br /> rose_setsockopt() and multiplied by extra values on top of that,<br /> integer overflows may occur.<br /> <br /> Do the safest minimum and fix these issues by checking the<br /> contents of &amp;#39;opt&amp;#39; and returning -EINVAL if they are too large. Also,<br /> switch to unsigned int and remove useless check for negative &amp;#39;opt&amp;#39;<br /> in ROSE_IDLE case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetime<br /> <br /> After commit ec6bb299c7c3 ("md/md-bitmap: add &amp;#39;sync_size&amp;#39; into struct<br /> md_bitmap_stats"), following panic is reported:<br /> <br /> Oops: general protection fault, probably for non-canonical address<br /> RIP: 0010:bitmap_get_stats+0x2b/0xa0<br /> Call Trace:<br /> <br /> md_seq_show+0x2d2/0x5b0<br /> seq_read_iter+0x2b9/0x470<br /> seq_read+0x12f/0x180<br /> proc_reg_read+0x57/0xb0<br /> vfs_read+0xf6/0x380<br /> ksys_read+0x6c/0xf0<br /> do_syscall_64+0x82/0x170<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Root cause is that bitmap_get_stats() can be called at anytime if mddev<br /> is still there, even if bitmap is destroyed, or not fully initialized.<br /> Deferenceing bitmap in this case can crash the kernel. Meanwhile, the<br /> above commit start to deferencing bitmap-&gt;storage, make the problem<br /> easier to trigger.<br /> <br /> Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: correct handling of extreme memory squeeze<br /> <br /> Testing with iperf3 using the "pasta" protocol splicer has revealed<br /> a problem in the way tcp handles window advertising in extreme memory<br /> squeeze situations.<br /> <br /> Under memory pressure, a socket endpoint may temporarily advertise<br /> a zero-sized window, but this is not stored as part of the socket data.<br /> The reasoning behind this is that it is considered a temporary setting<br /> which shouldn&amp;#39;t influence any further calculations.<br /> <br /> However, if we happen to stall at an unfortunate value of the current<br /> window size, the algorithm selecting a new value will consistently fail<br /> to advertise a non-zero window once we have freed up enough memory.<br /> This means that this side&amp;#39;s notion of the current window size is<br /> different from the one last advertised to the peer, causing the latter<br /> to not send any data to resolve the sitution.<br /> <br /> The problem occurs on the iperf3 server side, and the socket in question<br /> is a completely regular socket with the default settings for the<br /> fedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.<br /> <br /> The following excerpt of a logging session, with own comments added,<br /> shows more in detail what is happening:<br /> <br /> // tcp_v4_rcv(-&gt;)<br /> // tcp_rcv_established(-&gt;)<br /> [520139222]: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====<br /> [520139222]: tcp_data_queue(-&gt;)<br /> [520139222]: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM<br /> [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]<br /> [copied_seq 259909392-&gt;260034360 (124968), unread 5565800, qlen 85, ofoq 0]<br /> [OFO queue: gap: 65480, len: 0]<br /> [520139222]: tcp_data_queue()<br /> [tp-&gt;rcv_wup: 265469200, tp-&gt;rcv_wnd: 262144, tp-&gt;rcv_nxt 265600160]<br /> [520139222]: tcp_select_window(-&gt;)<br /> [520139222]: (inet_csk(sk)-&gt;icsk_ack.pending &amp; ICSK_ACK_NOMEM) ? --&gt; TRUE<br /> [tp-&gt;rcv_wup: 265469200, tp-&gt;rcv_wnd: 262144, tp-&gt;rcv_nxt 265600160]<br /> returning 0<br /> [520139222]: tcp_select_window() tp-&gt;rcv_wup: 265469200, tp-&gt;rcv_wnd: 262144, tp-&gt;rcv_nxt 265600160<br /> [520139222]: [new_win = 0, win_now = 131184, 2 * win_now = 262368]<br /> [520139222]: [new_win &gt;= (2 * win_now) ? --&gt; time_to_ack = 0]<br /> [520139222]: NOT calling tcp_send_ack()<br /> [tp-&gt;rcv_wup: 265469200, tp-&gt;rcv_wnd: 262144, tp-&gt;rcv_nxt 265600160]<br /> [520139222]: __tcp_cleanup_rbuf(260040464 (0), unread 5559696, qlen 85, ofoq 0]<br /> returning 6104 bytes<br /> [520139222]: tcp_recvmsg_locked(rcv_wnd.<br /> // Meanwhile, the peer thinks the window is zero, and will not send<br /> // any more data to trigger an update from the interrupt mode side.<br /> <br /> [520139222]: tcp_recvmsg_locked(-&gt;)<br /> [520139222]: __tcp_cleanup_rbuf(-&gt;) tp-&gt;rcv_wup: 265469200, tp-&gt;rcv_wnd: 262144, tp-&gt;rcv_nxt 265600160<br /> [520139222]: [new_win = 262144, win_now = 131184, 2 * win_n<br /> ---truncated---

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: wilc1000: unregister wiphy only if it has been registered<br /> <br /> There is a specific error path in probe functions in wilc drivers (both<br /> sdio and spi) which can lead to kernel panic, as this one for example<br /> when using SPI:<br /> <br /> Unable to handle kernel paging request at virtual address 9f000000 when read<br /> [9f000000] *pgd=00000000<br /> Internal error: Oops: 5 [#1] ARM<br /> Modules linked in: wilc1000_spi(+) crc_itu_t crc7 wilc1000 cfg80211 bluetooth ecdh_generic ecc<br /> CPU: 0 UID: 0 PID: 106 Comm: modprobe Not tainted 6.13.0-rc3+ #22<br /> Hardware name: Atmel SAMA5<br /> PC is at wiphy_unregister+0x244/0xc40 [cfg80211]<br /> LR is at wiphy_unregister+0x1c0/0xc40 [cfg80211]<br /> [...]<br /> wiphy_unregister [cfg80211] from wilc_netdev_cleanup+0x380/0x494 [wilc1000]<br /> wilc_netdev_cleanup [wilc1000] from wilc_bus_probe+0x360/0x834 [wilc1000_spi]<br /> wilc_bus_probe [wilc1000_spi] from spi_probe+0x15c/0x1d4<br /> spi_probe from really_probe+0x270/0xb2c<br /> really_probe from __driver_probe_device+0x1dc/0x4e8<br /> __driver_probe_device from driver_probe_device+0x5c/0x140<br /> driver_probe_device from __driver_attach+0x220/0x540<br /> __driver_attach from bus_for_each_dev+0x13c/0x1a8<br /> bus_for_each_dev from bus_add_driver+0x2a0/0x6a4<br /> bus_add_driver from driver_register+0x27c/0x51c<br /> driver_register from do_one_initcall+0xf8/0x564<br /> do_one_initcall from do_init_module+0x2e4/0x82c<br /> do_init_module from load_module+0x59a0/0x70c4<br /> load_module from init_module_from_file+0x100/0x148<br /> init_module_from_file from sys_finit_module+0x2fc/0x924<br /> sys_finit_module from ret_fast_syscall+0x0/0x1c<br /> <br /> The issue can easily be reproduced, for example by not wiring correctly<br /> a wilc device through SPI (and so, make it unresponsive to early SPI<br /> commands). It is due to a recent change decoupling wiphy allocation from<br /> wiphy registration, however wilc_netdev_cleanup has not been updated<br /> accordingly, letting it possibly call wiphy unregister on a wiphy which<br /> has never been registered.<br /> <br /> Fix this crash by moving wiphy_unregister/wiphy_free out of<br /> wilc_netdev_cleanup, and by adjusting error paths in both drivers

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 /> 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 /> 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 /> HID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint check<br /> <br /> syzbot has found a type mismatch between a USB pipe and the transfer<br /> endpoint, which is triggered by the hid-thrustmaster driver[1].<br /> There is a number of similar, already fixed issues [2].<br /> In this case as in others, implementing check for endpoint type fixes the issue.<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470<br /> [2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622