Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: handle errors that nilfs_prepare_chunk() may return<br /> <br /> Patch series "nilfs2: fix issues with rename operations".<br /> <br /> This series fixes BUG_ON check failures reported by syzbot around rename<br /> operations, and a minor behavioral issue where the mtime of a child<br /> directory changes when it is renamed instead of moved.<br /> <br /> <br /> This patch (of 2):<br /> <br /> The directory manipulation routines nilfs_set_link() and<br /> nilfs_delete_entry() rewrite the directory entry in the folio/page<br /> previously read by nilfs_find_entry(), so error handling is omitted on the<br /> assumption that nilfs_prepare_chunk(), which prepares the buffer for<br /> rewriting, will always succeed for these. And if an error is returned, it<br /> triggers the legacy BUG_ON() checks in each routine.<br /> <br /> This assumption is wrong, as proven by syzbot: the buffer layer called by<br /> nilfs_prepare_chunk() may call nilfs_get_block() if necessary, which may<br /> fail due to metadata corruption or other reasons. This has been there all<br /> along, but improved sanity checks and error handling may have made it more<br /> reproducible in fuzzing tests.<br /> <br /> Fix this issue by adding missing error paths in nilfs_set_link(),<br /> nilfs_delete_entry(), and their caller nilfs_rename().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: do not force clear folio if buffer is referenced<br /> <br /> Patch series "nilfs2: protect busy buffer heads from being force-cleared".<br /> <br /> This series fixes the buffer head state inconsistency issues reported by<br /> syzbot that occurs when the filesystem is corrupted and falls back to<br /> read-only, and the associated buffer head use-after-free issue.<br /> <br /> <br /> This patch (of 2):<br /> <br /> Syzbot has reported that after nilfs2 detects filesystem corruption and<br /> falls back to read-only, inconsistencies in the buffer state may occur.<br /> <br /> One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty()<br /> to set a data or metadata buffer as dirty, but it detects that the buffer<br /> is not in the uptodate state:<br /> <br /> WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520<br /> fs/buffer.c:1177<br /> ...<br /> Call Trace:<br /> <br /> nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598<br /> nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73<br /> nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344<br /> nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218<br /> vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257<br /> do_mkdirat+0x264/0x3a0 fs/namei.c:4280<br /> __do_sys_mkdirat fs/namei.c:4295 [inline]<br /> __se_sys_mkdirat fs/namei.c:4293 [inline]<br /> __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> The other is when nilfs_btree_propagate(), which propagates the dirty<br /> state to the ancestor nodes of a b-tree that point to a dirty buffer,<br /> detects that the origin buffer is not dirty, even though it should be:<br /> <br /> WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089<br /> nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089<br /> ...<br /> Call Trace:<br /> <br /> nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345<br /> nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587<br /> nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006<br /> nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045<br /> nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline]<br /> nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline]<br /> nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115<br /> nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479<br /> nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline]<br /> nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> <br /> Both of these issues are caused by the callbacks that handle the<br /> page/folio write requests, forcibly clear various states, including the<br /> working state of the buffers they hold, at unexpected times when they<br /> detect read-only fallback.<br /> <br /> Fix these issues by checking if the buffer is referenced before clearing<br /> the page/folio state, and skipping the clear if it is.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: prevent reg-wait speculations<br /> <br /> With *ENTER_EXT_ARG_REG instead of passing a user pointer with arguments<br /> for the waiting loop the user can specify an offset into a pre-mapped<br /> region of memory, in which case the<br /> [offset, offset + sizeof(io_uring_reg_wait)) will be intepreted as the<br /> argument.<br /> <br /> As we address a kernel array using a user given index, it&amp;#39;d be a subject<br /> to speculation type of exploits. Use array_index_nospec() to prevent<br /> that. Make sure to pass not the full region size but truncate by the<br /> maximum offset allowed considering the structure size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kernel: be more careful about dup_mmap() failures and uprobe registering<br /> <br /> If a memory allocation fails during dup_mmap(), the maple tree can be left<br /> in an unsafe state for other iterators besides the exit path. All the<br /> locks are dropped before the exit_mmap() call (in mm/mmap.c), but the<br /> incomplete mm_struct can be reached through (at least) the rmap finding<br /> the vmas which have a pointer back to the mm_struct.<br /> <br /> Up to this point, there have been no issues with being able to find an<br /> mm_struct that was only partially initialised. Syzbot was able to make<br /> the incomplete mm_struct fail with recent forking changes, so it has been<br /> proven unsafe to use the mm_struct that hasn&amp;#39;t been initialised, as<br /> referenced in the link below.<br /> <br /> Although 8ac662f5da19f ("fork: avoid inappropriate uprobe access to<br /> invalid mm") fixed the uprobe access, it does not completely remove the<br /> race.<br /> <br /> This patch sets the MMF_OOM_SKIP to avoid the iteration of the vmas on the<br /> oom side (even though this is extremely unlikely to be selected as an oom<br /> victim in the race window), and sets MMF_UNSTABLE to avoid other potential<br /> users from using a partially initialised mm_struct.<br /> <br /> When registering vmas for uprobe, skip the vmas in an mm that is marked<br /> unstable. Modifying a vma in an unstable mm may cause issues if the mm<br /> isn&amp;#39;t fully initialised.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries/iommu: Don&amp;#39;t unset window if it was never set<br /> <br /> On pSeries, when user attempts to use the same vfio container used by<br /> different iommu group, the spapr_tce_set_window() returns -EPERM<br /> and the subsequent cleanup leads to the below crash.<br /> <br /> Kernel attempted to read user page (308) - exploit attempt?<br /> BUG: Kernel NULL pointer dereference on read at 0x00000308<br /> Faulting instruction address: 0xc0000000001ce358<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> NIP: c0000000001ce358 LR: c0000000001ce05c CTR: c00000000005add0<br /> <br /> NIP [c0000000001ce358] spapr_tce_unset_window+0x3b8/0x510<br /> LR [c0000000001ce05c] spapr_tce_unset_window+0xbc/0x510<br /> Call Trace:<br /> spapr_tce_unset_window+0xbc/0x510 (unreliable)<br /> tce_iommu_attach_group+0x24c/0x340 [vfio_iommu_spapr_tce]<br /> vfio_container_attach_group+0xec/0x240 [vfio]<br /> vfio_group_fops_unl_ioctl+0x548/0xb00 [vfio]<br /> sys_ioctl+0x754/0x1580<br /> system_call_exception+0x13c/0x330<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> --- interrupt: 3000<br /> <br /> Fix this by having null check for the tbl passed to the<br /> spapr_tce_unset_window().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: handle fastopen disconnect correctly<br /> <br /> Syzbot was able to trigger a data stream corruption:<br /> <br /> WARNING: CPU: 0 PID: 9846 at net/mptcp/protocol.c:1024 __mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 9846 Comm: syz-executor351 Not tainted 6.13.0-rc2-syzkaller-00059-g00a5acdbf398 #0<br /> Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024<br /> RIP: 0010:__mptcp_clean_una+0xddb/0xff0 net/mptcp/protocol.c:1024<br /> Code: fa ff ff 48 8b 4c 24 18 80 e1 07 fe c1 38 c1 0f 8c 8e fa ff ff 48 8b 7c 24 18 e8 e0 db 54 f6 e9 7f fa ff ff e8 e6 80 ee f5 90 0b 90 4c 8b 6c 24 40 4d 89 f4 e9 04 f5 ff ff 44 89 f1 80 e1 07<br /> RSP: 0018:ffffc9000c0cf400 EFLAGS: 00010293<br /> RAX: ffffffff8bb0dd5a RBX: ffff888033f5d230 RCX: ffff888059ce8000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffc9000c0cf518 R08: ffffffff8bb0d1dd R09: 1ffff110170c8928<br /> R10: dffffc0000000000 R11: ffffed10170c8929 R12: 0000000000000000<br /> R13: ffff888033f5d220 R14: dffffc0000000000 R15: ffff8880592b8000<br /> FS: 00007f6e866496c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f6e86f491a0 CR3: 00000000310e6000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __mptcp_clean_una_wakeup+0x7f/0x2d0 net/mptcp/protocol.c:1074<br /> mptcp_release_cb+0x7cb/0xb30 net/mptcp/protocol.c:3493<br /> release_sock+0x1aa/0x1f0 net/core/sock.c:3640<br /> inet_wait_for_connect net/ipv4/af_inet.c:609 [inline]<br /> __inet_stream_connect+0x8bd/0xf30 net/ipv4/af_inet.c:703<br /> mptcp_sendmsg_fastopen+0x2a2/0x530 net/mptcp/protocol.c:1755<br /> mptcp_sendmsg+0x1884/0x1b10 net/mptcp/protocol.c:1830<br /> sock_sendmsg_nosec net/socket.c:711 [inline]<br /> __sock_sendmsg+0x1a6/0x270 net/socket.c:726<br /> ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583<br /> ___sys_sendmsg net/socket.c:2637 [inline]<br /> __sys_sendmsg+0x269/0x350 net/socket.c:2669<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f6e86ebfe69<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 1f 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f6e86649168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f6e86f491b8 RCX: 00007f6e86ebfe69<br /> RDX: 0000000030004001 RSI: 0000000020000080 RDI: 0000000000000003<br /> RBP: 00007f6e86f491b0 R08: 00007f6e866496c0 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f6e86f491bc<br /> R13: 000000000000006e R14: 00007ffe445d9420 R15: 00007ffe445d9508<br /> <br /> <br /> The root cause is the bad handling of disconnect() generated internally<br /> by the MPTCP protocol in case of connect FASTOPEN errors.<br /> <br /> Address the issue increasing the socket disconnect counter even on such<br /> a case, to allow other threads waiting on the same socket lock to<br /> properly error out.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: pm: only set fullmesh for subflow endp<br /> <br /> With the in-kernel path-manager, it is possible to change the &amp;#39;fullmesh&amp;#39;<br /> flag. The code in mptcp_pm_nl_fullmesh() expects to change it only on<br /> &amp;#39;subflow&amp;#39; endpoints, to recreate more or less subflows using the linked<br /> address.<br /> <br /> Unfortunately, the set_flags() hook was a bit more permissive, and<br /> allowed &amp;#39;implicit&amp;#39; endpoints to get the &amp;#39;fullmesh&amp;#39; flag while it is not<br /> allowed before.<br /> <br /> That&amp;#39;s what syzbot found, triggering the following warning:<br /> <br /> WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 __mark_subflow_endp_available net/mptcp/pm_netlink.c:1496 [inline]<br /> WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_pm_nl_fullmesh net/mptcp/pm_netlink.c:1980 [inline]<br /> WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_nl_set_flags net/mptcp/pm_netlink.c:2003 [inline]<br /> WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_pm_nl_set_flags+0x974/0xdc0 net/mptcp/pm_netlink.c:2064<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 6499 Comm: syz.1.413 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0<br /> Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_netlink.c:1496 [inline]<br /> RIP: 0010:mptcp_pm_nl_fullmesh net/mptcp/pm_netlink.c:1980 [inline]<br /> RIP: 0010:mptcp_nl_set_flags net/mptcp/pm_netlink.c:2003 [inline]<br /> RIP: 0010:mptcp_pm_nl_set_flags+0x974/0xdc0 net/mptcp/pm_netlink.c:2064<br /> Code: 01 00 00 49 89 c5 e8 fb 45 e8 f5 e9 b8 fc ff ff e8 f1 45 e8 f5 4c 89 f7 be 03 00 00 00 e8 44 1d 0b f9 eb a0 e8 dd 45 e8 f5 90 0b 90 e9 17 ff ff ff 89 d9 80 e1 07 38 c1 0f 8c c9 fc ff ff 48<br /> RSP: 0018:ffffc9000d307240 EFLAGS: 00010293<br /> RAX: ffffffff8bb72e03 RBX: 0000000000000000 RCX: ffff88807da88000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffc9000d307430 R08: ffffffff8bb72cf0 R09: 1ffff1100b842a5e<br /> R10: dffffc0000000000 R11: ffffed100b842a5f R12: ffff88801e2e5ac0<br /> R13: ffff88805c214800 R14: ffff88805c2152e8 R15: 1ffff1100b842a5d<br /> FS: 00005555619f6500(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020002840 CR3: 00000000247e6000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]<br /> genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]<br /> genl_rcv_msg+0xb14/0xec0 net/netlink/genetlink.c:1210<br /> netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2542<br /> genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]<br /> netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1347<br /> netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1891<br /> sock_sendmsg_nosec net/socket.c:711 [inline]<br /> __sock_sendmsg+0x221/0x270 net/socket.c:726<br /> ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583<br /> ___sys_sendmsg net/socket.c:2637 [inline]<br /> __sys_sendmsg+0x269/0x350 net/socket.c:2669<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f5fe8785d29<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fff571f5558 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f5fe8975fa0 RCX: 00007f5fe8785d29<br /> RDX: 0000000000000000 RSI: 0000000020000480 RDI: 0000000000000007<br /> RBP: 00007f5fe8801b08 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007f5fe8975fa0 R14: 00007f5fe8975fa0 R15: 000000<br /> ---truncated---

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