Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: better track kernel sockets lifetime<br /> <br /> While kernel sockets are dismantled during pernet_operations-&gt;exit(),<br /> their freeing can be delayed by any tx packets still held in qdisc<br /> or device queues, due to skb_set_owner_w() prior calls.<br /> <br /> This then trigger the following warning from ref_tracker_dir_exit() [1]<br /> <br /> To fix this, make sure that kernel sockets own a reference on net-&gt;passive.<br /> <br /> Add sk_net_refcnt_upgrade() helper, used whenever a kernel socket<br /> is converted to a refcounted one.<br /> <br /> [1]<br /> <br /> [ 136.263918][ T35] ref_tracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at<br /> [ 136.263918][ T35] sk_alloc+0x2b3/0x370<br /> [ 136.263918][ T35] inet6_create+0x6ce/0x10f0<br /> [ 136.263918][ T35] __sock_create+0x4c0/0xa30<br /> [ 136.263918][ T35] inet_ctl_sock_create+0xc2/0x250<br /> [ 136.263918][ T35] igmp6_net_init+0x39/0x390<br /> [ 136.263918][ T35] ops_init+0x31e/0x590<br /> [ 136.263918][ T35] setup_net+0x287/0x9e0<br /> [ 136.263918][ T35] copy_net_ns+0x33f/0x570<br /> [ 136.263918][ T35] create_new_namespaces+0x425/0x7b0<br /> [ 136.263918][ T35] unshare_nsproxy_namespaces+0x124/0x180<br /> [ 136.263918][ T35] ksys_unshare+0x57d/0xa70<br /> [ 136.263918][ T35] __x64_sys_unshare+0x38/0x40<br /> [ 136.263918][ T35] do_syscall_64+0xf3/0x230<br /> [ 136.263918][ T35] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 136.263918][ T35]<br /> [ 136.343488][ T35] ref_tracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at<br /> [ 136.343488][ T35] sk_alloc+0x2b3/0x370<br /> [ 136.343488][ T35] inet6_create+0x6ce/0x10f0<br /> [ 136.343488][ T35] __sock_create+0x4c0/0xa30<br /> [ 136.343488][ T35] inet_ctl_sock_create+0xc2/0x250<br /> [ 136.343488][ T35] ndisc_net_init+0xa7/0x2b0<br /> [ 136.343488][ T35] ops_init+0x31e/0x590<br /> [ 136.343488][ T35] setup_net+0x287/0x9e0<br /> [ 136.343488][ T35] copy_net_ns+0x33f/0x570<br /> [ 136.343488][ T35] create_new_namespaces+0x425/0x7b0<br /> [ 136.343488][ T35] unshare_nsproxy_namespaces+0x124/0x180<br /> [ 136.343488][ T35] ksys_unshare+0x57d/0xa70<br /> [ 136.343488][ T35] __x64_sys_unshare+0x38/0x40<br /> [ 136.343488][ T35] do_syscall_64+0xf3/0x230<br /> [ 136.343488][ T35] entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/bnxt_re: Fix the page details for the srq created by kernel consumers<br /> <br /> While using nvme target with use_srq on, below kernel panic is noticed.<br /> <br /> [ 549.698111] bnxt_en 0000:41:00.0 enp65s0np0: FEC autoneg off encoding: Clause 91 RS(544,514)<br /> [ 566.393619] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI<br /> ..<br /> [ 566.393799] <br /> [ 566.393807] ? __die_body+0x1a/0x60<br /> [ 566.393823] ? die+0x38/0x60<br /> [ 566.393835] ? do_trap+0xe4/0x110<br /> [ 566.393847] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]<br /> [ 566.393867] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]<br /> [ 566.393881] ? do_error_trap+0x7c/0x120<br /> [ 566.393890] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]<br /> [ 566.393911] ? exc_divide_error+0x34/0x50<br /> [ 566.393923] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]<br /> [ 566.393939] ? asm_exc_divide_error+0x16/0x20<br /> [ 566.393966] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re]<br /> [ 566.393997] bnxt_qplib_create_srq+0xc9/0x340 [bnxt_re]<br /> [ 566.394040] bnxt_re_create_srq+0x335/0x3b0 [bnxt_re]<br /> [ 566.394057] ? srso_return_thunk+0x5/0x5f<br /> [ 566.394068] ? __init_swait_queue_head+0x4a/0x60<br /> [ 566.394090] ib_create_srq_user+0xa7/0x150 [ib_core]<br /> [ 566.394147] nvmet_rdma_queue_connect+0x7d0/0xbe0 [nvmet_rdma]<br /> [ 566.394174] ? lock_release+0x22c/0x3f0<br /> [ 566.394187] ? srso_return_thunk+0x5/0x5f<br /> <br /> Page size and shift info is set only for the user space SRQs.<br /> Set page size and page shift for kernel space SRQs also.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix implicit ODP hang on parent deregistration<br /> <br /> Fix the destroy_unused_implicit_child_mr() to prevent hanging during<br /> parent deregistration as of below [1].<br /> <br /> Upon entering destroy_unused_implicit_child_mr(), the reference count<br /> for the implicit MR parent is incremented using:<br /> refcount_inc_not_zero().<br /> <br /> A corresponding decrement must be performed if<br /> free_implicit_child_mr_work() is not called.<br /> <br /> The code has been updated to properly manage the reference count that<br /> was incremented.<br /> <br /> [1]<br /> INFO: task python3:2157 blocked for more than 120 seconds.<br /> Not tainted 6.12.0-rc7+ #1633<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:python3 state:D stack:0 pid:2157 tgid:2157 ppid:1685 flags:0x00000000<br /> Call Trace:<br /> <br /> __schedule+0x420/0xd30<br /> schedule+0x47/0x130<br /> __mlx5_ib_dereg_mr+0x379/0x5d0 [mlx5_ib]<br /> ? __pfx_autoremove_wake_function+0x10/0x10<br /> ib_dereg_mr_user+0x5f/0x120 [ib_core]<br /> ? lock_release+0xc6/0x280<br /> destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs]<br /> uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs]<br /> uobj_destroy+0x3f/0x70 [ib_uverbs]<br /> ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs]<br /> ? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs]<br /> ? lock_acquire+0xc1/0x2f0<br /> ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]<br /> ? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs]<br /> ? lock_release+0xc6/0x280<br /> ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]<br /> ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]<br /> __x64_sys_ioctl+0x1b0/0xa70<br /> ? kmem_cache_free+0x221/0x400<br /> do_syscall_64+0x6b/0x140<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f20f21f017b<br /> RSP: 002b:00007ffcfc4a77c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007ffcfc4a78d8 RCX: 00007f20f21f017b<br /> RDX: 00007ffcfc4a78c0 RSI: 00000000c0181b01 RDI: 0000000000000003<br /> RBP: 00007ffcfc4a78a0 R08: 000056147d125190 R09: 00007f20f1f14c60<br /> R10: 0000000000000001 R11: 0000000000000246 R12: 00007ffcfc4a7890<br /> R13: 000000000000001c R14: 000056147d100fc0 R15: 00007f20e365c9d0<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix a WARN during dereg_mr for DM type<br /> <br /> Memory regions (MR) of type DM (device memory) do not have an associated<br /> umem.<br /> <br /> In the __mlx5_ib_dereg_mr() -&gt; mlx5_free_priv_descs() flow, the code<br /> incorrectly takes the wrong branch, attempting to call<br /> dma_unmap_single() on a DMA address that is not mapped.<br /> <br /> This results in a WARN [1], as shown below.<br /> <br /> The issue is resolved by properly accounting for the DM type and<br /> ensuring the correct branch is selected in mlx5_free_priv_descs().<br /> <br /> [1]<br /> WARNING: CPU: 12 PID: 1346 at drivers/iommu/dma-iommu.c:1230 iommu_dma_unmap_page+0x79/0x90<br /> Modules linked in: ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry ovelay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core<br /> CPU: 12 UID: 0 PID: 1346 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1631<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:iommu_dma_unmap_page+0x79/0x90<br /> Code: 2b 49 3b 29 72 26 49 3b 69 08 73 20 4d 89 f0 44 89 e9 4c 89 e2 48 89 ee 48 89 df 5b 5d 41 5c 41 5d 41 5e 41 5f e9 07 b8 88 ff 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 66 0f 1f 44 00<br /> RSP: 0018:ffffc90001913a10 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff88810194b0a8 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001<br /> RBP: ffff88810194b0a8 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000<br /> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 00007f537abdd740(0000) GS:ffff88885fb00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f537aeb8000 CR3: 000000010c248001 CR4: 0000000000372eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __warn+0x84/0x190<br /> ? iommu_dma_unmap_page+0x79/0x90<br /> ? report_bug+0xf8/0x1c0<br /> ? handle_bug+0x55/0x90<br /> ? exc_invalid_op+0x13/0x60<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? iommu_dma_unmap_page+0x79/0x90<br /> dma_unmap_page_attrs+0xe6/0x290<br /> mlx5_free_priv_descs+0xb0/0xe0 [mlx5_ib]<br /> __mlx5_ib_dereg_mr+0x37e/0x520 [mlx5_ib]<br /> ? _raw_spin_unlock_irq+0x24/0x40<br /> ? wait_for_completion+0xfe/0x130<br /> ? rdma_restrack_put+0x63/0xe0 [ib_core]<br /> ib_dereg_mr_user+0x5f/0x120 [ib_core]<br /> ? lock_release+0xc6/0x280<br /> destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs]<br /> uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs]<br /> uobj_destroy+0x3f/0x70 [ib_uverbs]<br /> ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs]<br /> ? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs]<br /> ? lock_acquire+0xc1/0x2f0<br /> ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]<br /> ? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs]<br /> ? lock_release+0xc6/0x280<br /> ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]<br /> ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]<br /> __x64_sys_ioctl+0x1b0/0xa70<br /> do_syscall_64+0x6b/0x140<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f537adaf17b<br /> Code: 0f 1e fa 48 8b 05 1d ad 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed ac 0c 00 f7 d8 64 89 01 48<br /> RSP: 002b:00007ffff218f0b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007ffff218f1d8 RCX: 00007f537adaf17b<br /> RDX: 00007ffff218f1c0 RSI: 00000000c0181b01 RDI: 0000000000000003<br /> RBP: 00007ffff218f1a0 R08: 00007f537aa8d010 R09: 0000561ee2e4f270<br /> R10: 00007f537aace3a8 R11: 0000000000000246 R12: 00007ffff218f190<br /> R13: 000000000000001c R14: 0000561ee2e4d7c0 R15: 00007ffff218f450<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/core: Add RCU read lock protection to perf_iterate_ctx()<br /> <br /> The perf_iterate_ctx() function performs RCU list traversal but<br /> currently lacks RCU read lock protection. This causes lockdep warnings<br /> when running perf probe with unshare(1) under CONFIG_PROVE_RCU_LIST=y:<br /> <br /> WARNING: suspicious RCU usage<br /> kernel/events/core.c:8168 RCU-list traversed in non-reader section!!<br /> <br /> Call Trace:<br /> lockdep_rcu_suspicious<br /> ? perf_event_addr_filters_apply<br /> perf_iterate_ctx<br /> perf_event_exec<br /> begin_new_exec<br /> ? load_elf_phdrs<br /> load_elf_binary<br /> ? lock_acquire<br /> ? find_held_lock<br /> ? bprm_execve<br /> bprm_execve<br /> do_execveat_common.isra.0<br /> __x64_sys_execve<br /> do_syscall_64<br /> entry_SYSCALL_64_after_hwframe<br /> <br /> This protection was previously present but was removed in commit<br /> bd2756811766 ("perf: Rewrite core context handling"). Add back the<br /> necessary rcu_read_lock()/rcu_read_unlock() pair around<br /> perf_iterate_ctx() call in perf_event_exec().<br /> <br /> [ mingo: Use scoped_guard() as suggested by Peter ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix checksums set in idpf_rx_rsc()<br /> <br /> idpf_rx_rsc() uses skb_transport_offset(skb) while the transport header<br /> is not set yet.<br /> <br /> This triggers the following warning for CONFIG_DEBUG_NET=y builds.<br /> <br /> DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb))<br /> <br /> [ 69.261620] WARNING: CPU: 7 PID: 0 at ./include/linux/skbuff.h:3020 idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf<br /> [ 69.261629] Modules linked in: vfat fat dummy bridge intel_uncore_frequency_tpmi intel_uncore_frequency_common intel_vsec_tpmi idpf intel_vsec cdc_ncm cdc_eem cdc_ether usbnet mii xhci_pci xhci_hcd ehci_pci ehci_hcd libeth<br /> [ 69.261644] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Tainted: G S W 6.14.0-smp-DEV #1697<br /> [ 69.261648] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN<br /> [ 69.261650] RIP: 0010:idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf<br /> [ 69.261677] ? __warn (kernel/panic.c:242 kernel/panic.c:748)<br /> [ 69.261682] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf<br /> [ 69.261687] ? report_bug (lib/bug.c:?)<br /> [ 69.261690] ? handle_bug (arch/x86/kernel/traps.c:285)<br /> [ 69.261694] ? exc_invalid_op (arch/x86/kernel/traps.c:309)<br /> [ 69.261697] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)<br /> [ 69.261700] ? __pfx_idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:4011) idpf<br /> [ 69.261704] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf<br /> [ 69.261708] ? idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:3072) idpf<br /> [ 69.261712] __napi_poll (net/core/dev.c:7194)<br /> [ 69.261716] net_rx_action (net/core/dev.c:7265)<br /> [ 69.261718] ? __qdisc_run (net/sched/sch_generic.c:293)<br /> [ 69.261721] ? sched_clock (arch/x86/include/asm/preempt.h:84 arch/x86/kernel/tsc.c:288)<br /> [ 69.261726] handle_softirqs (kernel/softirq.c:561)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: bsg: Fix crash when arpmb command fails<br /> <br /> If the device doesn&amp;#39;t support arpmb we&amp;#39;ll crash due to copying user data in<br /> bsg_transport_sg_io_fn().<br /> <br /> In the case where ufs_bsg_exec_advanced_rpmb_req() returns an error, do not<br /> set the job&amp;#39;s reply_len.<br /> <br /> Memory crash backtrace:<br /> 3,1290,531166405,-;ufshcd 0000:00:12.5: ARPMB OP failed: error code -22<br /> <br /> 4,1308,531166555,-;Call Trace:<br /> <br /> 4,1309,531166559,-; <br /> <br /> 4,1310,531166565,-; ? show_regs+0x6d/0x80<br /> <br /> 4,1311,531166575,-; ? die+0x37/0xa0<br /> <br /> 4,1312,531166583,-; ? do_trap+0xd4/0xf0<br /> <br /> 4,1313,531166593,-; ? do_error_trap+0x71/0xb0<br /> <br /> 4,1314,531166601,-; ? usercopy_abort+0x6c/0x80<br /> <br /> 4,1315,531166610,-; ? exc_invalid_op+0x52/0x80<br /> <br /> 4,1316,531166622,-; ? usercopy_abort+0x6c/0x80<br /> <br /> 4,1317,531166630,-; ? asm_exc_invalid_op+0x1b/0x20<br /> <br /> 4,1318,531166643,-; ? usercopy_abort+0x6c/0x80<br /> <br /> 4,1319,531166652,-; __check_heap_object+0xe3/0x120<br /> <br /> 4,1320,531166661,-; check_heap_object+0x185/0x1d0<br /> <br /> 4,1321,531166670,-; __check_object_size.part.0+0x72/0x150<br /> <br /> 4,1322,531166679,-; __check_object_size+0x23/0x30<br /> <br /> 4,1323,531166688,-; bsg_transport_sg_io_fn+0x314/0x3b0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm-integrity: Avoid divide by zero in table status in Inline mode<br /> <br /> In Inline mode, the journal is unused, and journal_sectors is zero.<br /> <br /> Calculating the journal watermark requires dividing by journal_sectors,<br /> which should be done only if the journal is configured.<br /> <br /> Otherwise, a simple table query (dmsetup table) can cause OOPS.<br /> <br /> This bug did not show on some systems, perhaps only due to<br /> compiler optimization.<br /> <br /> On my 32-bit testing machine, this reliably crashes with the following:<br /> <br /> : Oops: divide error: 0000 [#1] PREEMPT SMP<br /> : CPU: 0 UID: 0 PID: 2450 Comm: dmsetup Not tainted 6.14.0-rc2+ #959<br /> : EIP: dm_integrity_status+0x2f8/0xab0 [dm_integrity]<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: always handle address removal under msk socket lock<br /> <br /> Syzkaller reported a lockdep splat in the PM control path:<br /> <br /> WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline]<br /> WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline]<br /> WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0<br /> Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024<br /> RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline]<br /> RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline]<br /> RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788<br /> Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff<br /> RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283<br /> RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000<br /> RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408<br /> RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000<br /> R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0<br /> R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00<br /> FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59<br /> mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486<br /> mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline]<br /> mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629<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+0xb1f/0xec0 net/netlink/genetlink.c:1210<br /> netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543<br /> genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline]<br /> netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348<br /> netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892<br /> sock_sendmsg_nosec net/socket.c:718 [inline]<br /> __sock_sendmsg+0x221/0x270 net/socket.c:733<br /> ____sys_sendmsg+0x53a/0x860 net/socket.c:2573<br /> ___sys_sendmsg net/socket.c:2627 [inline]<br /> __sys_sendmsg+0x269/0x350 net/socket.c:2659<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:0x7f7e9998cde9<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:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9<br /> RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007<br /> RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088<br /> <br /> Indeed the PM can try to send a RM_ADDR over a msk without acquiring<br /> first the msk socket lock.<br /> <br /> The bugged code-path comes from an early optimization: when there<br /> are no subflows, the PM should (usually) not send RM_ADDR<br /> notifications.<br /> <br /> The above statement is incorrect, as without locks another process<br /> could concur<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Fix suspicious RCU usage<br /> <br /> Commit ("iommu/vt-d: Allocate DMAR fault interrupts<br /> locally") moved the call to enable_drhd_fault_handling() to a code<br /> path that does not hold any lock while traversing the drhd list. Fix<br /> it by ensuring the dmar_global_lock lock is held when traversing the<br /> drhd list.<br /> <br /> Without this fix, the following warning is triggered:<br /> =============================<br /> WARNING: suspicious RCU usage<br /> 6.14.0-rc3 #55 Not tainted<br /> -----------------------------<br /> drivers/iommu/intel/dmar.c:2046 RCU-list traversed in non-reader section!!<br /> other info that might help us debug this:<br /> rcu_scheduler_active = 1, debug_locks = 1<br /> 2 locks held by cpuhp/1/23:<br /> #0: ffffffff84a67c50 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0<br /> #1: ffffffff84a6a380 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0<br /> stack backtrace:<br /> CPU: 1 UID: 0 PID: 23 Comm: cpuhp/1 Not tainted 6.14.0-rc3 #55<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xb7/0xd0<br /> lockdep_rcu_suspicious+0x159/0x1f0<br /> ? __pfx_enable_drhd_fault_handling+0x10/0x10<br /> enable_drhd_fault_handling+0x151/0x180<br /> cpuhp_invoke_callback+0x1df/0x990<br /> cpuhp_thread_fun+0x1ea/0x2c0<br /> smpboot_thread_fn+0x1f5/0x2e0<br /> ? __pfx_smpboot_thread_fn+0x10/0x10<br /> kthread+0x12a/0x2d0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x4a/0x60<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Holding the lock in enable_drhd_fault_handling() triggers a lockdep splat<br /> about a possible deadlock between dmar_global_lock and cpu_hotplug_lock.<br /> This is avoided by not holding dmar_global_lock when calling<br /> iommu_device_register(), which initiates the device probe process.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet: gl620a: fix endpoint checking in genelink_bind()<br /> <br /> Syzbot reports [1] a warning in usb_submit_urb() triggered by<br /> inconsistencies between expected and actually present endpoints<br /> in gl620a driver. Since genelink_bind() does not properly<br /> verify whether specified eps are in fact provided by the device,<br /> in this case, an artificially manufactured one, one may get a<br /> mismatch.<br /> <br /> Fix the issue by resorting to a usbnet utility function<br /> usbnet_get_endpoints(), usually reserved for this very problem.<br /> Check for endpoints and return early before proceeding further if<br /> any are missing.<br /> <br /> [1] Syzbot report:<br /> usb 5-1: Manufacturer: syz<br /> usb 5-1: SerialNumber: syz<br /> usb 5-1: config 0 descriptor??<br /> gl620a 5-1:0.23 usb0: register &amp;#39;gl620a&amp;#39; at usb-dummy_hcd.0-1, ...<br /> ------------[ cut here ]------------<br /> usb 5-1: BOGUS urb xfer, pipe 3 != type 1<br /> WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503<br /> Modules linked in:<br /> CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> Workqueue: mld mld_ifc_work<br /> RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503<br /> ...<br /> Call Trace:<br /> <br /> usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467<br /> __netdev_start_xmit include/linux/netdevice.h:5002 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:5011 [inline]<br /> xmit_one net/core/dev.c:3590 [inline]<br /> dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606<br /> sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343<br /> __dev_xmit_skb net/core/dev.c:3827 [inline]<br /> __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400<br /> dev_queue_xmit include/linux/netdevice.h:3168 [inline]<br /> neigh_resolve_output net/core/neighbour.c:1514 [inline]<br /> neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494<br /> neigh_output include/net/neighbour.h:539 [inline]<br /> ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141<br /> __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]<br /> ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226<br /> NF_HOOK_COND include/linux/netfilter.h:303 [inline]<br /> ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247<br /> dst_output include/net/dst.h:450 [inline]<br /> NF_HOOK include/linux/netfilter.h:314 [inline]<br /> NF_HOOK include/linux/netfilter.h:308 [inline]<br /> mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819<br /> mld_send_cr net/ipv6/mcast.c:2120 [inline]<br /> mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651<br /> process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229<br /> process_scheduled_works kernel/workqueue.c:3310 [inline]<br /> worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391<br /> kthread+0x2c1/0x3a0 kernel/kthread.c:389<br /> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: npcm: disable interrupt enable bit before devm_request_irq<br /> <br /> The customer reports that there is a soft lockup issue related to<br /> the i2c driver. After checking, the i2c module was doing a tx transfer<br /> and the bmc machine reboots in the middle of the i2c transaction, the i2c<br /> module keeps the status without being reset.<br /> <br /> Due to such an i2c module status, the i2c irq handler keeps getting<br /> triggered since the i2c irq handler is registered in the kernel booting<br /> process after the bmc machine is doing a warm rebooting.<br /> The continuous triggering is stopped by the soft lockup watchdog timer.<br /> <br /> Disable the interrupt enable bit in the i2c module before calling<br /> devm_request_irq to fix this issue since the i2c relative status bit<br /> is read-only.<br /> <br /> Here is the soft lockup log.<br /> [ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1]<br /> [ 28.183351] Modules linked in:<br /> [ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1<br /> [ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 28.208128] pc : __do_softirq+0xb0/0x368<br /> [ 28.212055] lr : __do_softirq+0x70/0x368<br /> [ 28.215972] sp : ffffff8035ebca00<br /> [ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780<br /> [ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0<br /> [ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b<br /> [ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff<br /> [ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000<br /> [ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2<br /> [ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250<br /> [ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434<br /> [ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198<br /> [ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40<br /> [ 28.290611] Call trace:<br /> [ 28.293052] __do_softirq+0xb0/0x368<br /> [ 28.296625] __irq_exit_rcu+0xe0/0x100<br /> [ 28.300374] irq_exit+0x14/0x20<br /> [ 28.303513] handle_domain_irq+0x68/0x90<br /> [ 28.307440] gic_handle_irq+0x78/0xb0<br /> [ 28.311098] call_on_irq_stack+0x20/0x38<br /> [ 28.315019] do_interrupt_handler+0x54/0x5c<br /> [ 28.319199] el1_interrupt+0x2c/0x4c<br /> [ 28.322777] el1h_64_irq_handler+0x14/0x20<br /> [ 28.326872] el1h_64_irq+0x74/0x78<br /> [ 28.330269] __setup_irq+0x454/0x780<br /> [ 28.333841] request_threaded_irq+0xd0/0x1b4<br /> [ 28.338107] devm_request_threaded_irq+0x84/0x100<br /> [ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0<br /> [ 28.346990] platform_probe+0x6c/0xc4<br /> [ 28.350653] really_probe+0xcc/0x45c<br /> [ 28.354227] __driver_probe_device+0x8c/0x160<br /> [ 28.358578] driver_probe_device+0x44/0xe0<br /> [ 28.362670] __driver_attach+0x124/0x1d0<br /> [ 28.366589] bus_for_each_dev+0x7c/0xe0<br /> [ 28.370426] driver_attach+0x28/0x30<br /> [ 28.373997] bus_add_driver+0x124/0x240<br /> [ 28.377830] driver_register+0x7c/0x124<br /> [ 28.381662] __platform_driver_register+0x2c/0x34<br /> [ 28.386362] npcm_i2c_init+0x3c/0x5c<br /> [ 28.389937] do_one_initcall+0x74/0x230<br /> [ 28.393768] kernel_init_freeable+0x24c/0x2b4<br /> [ 28.398126] kernel_init+0x28/0x130<br /> [ 28.401614] ret_from_fork+0x10/0x20<br /> [ 28.405189] Kernel panic - not syncing: softlockup: hung tasks<br /> [ 28.411011] SMP: stopping secondary CPUs<br /> [ 28.414933] Kernel Offset: disabled<br /> [ 28.418412] CPU features: 0x00000000,00000802<br /> [ 28.427644] Rebooting in 20 seconds..