Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: add mutual exclusion in proc_sctp_do_udp_port()<br /> <br /> We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start()<br /> or risk a crash as syzbot reported:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]<br /> CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025<br /> RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653<br /> Call Trace:<br /> <br /> udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181<br /> sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930<br /> proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553<br /> proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601<br /> iter_file_splice_write+0x91c/0x1150 fs/splice.c:738<br /> do_splice_from fs/splice.c:935 [inline]<br /> direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158<br /> splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102<br /> do_splice_direct_actor fs/splice.c:1201 [inline]<br /> do_splice_direct+0x174/0x240 fs/splice.c:1227<br /> do_sendfile+0xafd/0xe50 fs/read_write.c:1368<br /> __do_sys_sendfile64 fs/read_write.c:1429 [inline]<br /> __se_sys_sendfile64 fs/read_write.c:1415 [inline]<br /> __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets<br /> <br /> When calling netlbl_conn_setattr(), addr-&gt;sa_family is used<br /> to determine the function behavior. If sk is an IPv4 socket,<br /> but the connect function is called with an IPv6 address,<br /> the function calipso_sock_setattr() is triggered.<br /> Inside this function, the following code is executed:<br /> <br /> sk_fullsock(__sk) ? inet_sk(__sk)-&gt;pinet6 : NULL;<br /> <br /> Since sk is an IPv4 socket, pinet6 is NULL, leading to a<br /> null pointer dereference.<br /> <br /> This patch fixes the issue by checking if inet6_sk(sk)<br /> returns a NULL pointer before accessing pinet6.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: gpib: Fix Oops after disconnect in agilent usb<br /> <br /> If the agilent usb dongle is disconnected subsequent calls to the<br /> driver cause a NULL dereference Oops as the bus_interface<br /> is set to NULL on disconnect.<br /> <br /> This problem was introduced by setting usb_dev from the bus_interface<br /> for dev_xxx messages.<br /> <br /> Previously bus_interface was checked for NULL only in the functions<br /> directly calling usb_fill_bulk_urb or usb_control_msg.<br /> <br /> Check for valid bus_interface on all interface entry points<br /> and return -ENODEV if it is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: gpib: Fix Oops after disconnect in ni_usb<br /> <br /> If the usb dongle is disconnected subsequent calls to the<br /> driver cause a NULL dereference Oops as the bus_interface<br /> is set to NULL on disconnect.<br /> <br /> This problem was introduced by setting usb_dev from the bus_interface<br /> for dev_xxx messages.<br /> <br /> Previously bus_interface was checked for NULL only in the the functions<br /> directly calling usb_fill_bulk_urb or usb_control_msg.<br /> <br /> Check for valid bus_interface on all interface entry points<br /> and return -ENODEV if it is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ibmveth: make veth_pool_store stop hanging<br /> <br /> v2:<br /> - Created a single error handling unlock and exit in veth_pool_store<br /> - Greatly expanded commit message with previous explanatory-only text<br /> <br /> Summary: Use rtnl_mutex to synchronize veth_pool_store with itself,<br /> ibmveth_close and ibmveth_open, preventing multiple calls in a row to<br /> napi_disable.<br /> <br /> Background: Two (or more) threads could call veth_pool_store through<br /> writing to /sys/devices/vio/30000002/pool*/*. You can do this easily<br /> with a little shell script. This causes a hang.<br /> <br /> I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new<br /> kernel. I ran this test again and saw:<br /> <br /> Setting pool0/active to 0<br /> Setting pool1/active to 1<br /> [ 73.911067][ T4365] ibmveth 30000002 eth0: close starting<br /> Setting pool1/active to 1<br /> Setting pool1/active to 0<br /> [ 73.911367][ T4366] ibmveth 30000002 eth0: close starting<br /> [ 73.916056][ T4365] ibmveth 30000002 eth0: close complete<br /> [ 73.916064][ T4365] ibmveth 30000002 eth0: open starting<br /> [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification.<br /> [ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification.<br /> [ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds.<br /> [ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8<br /> [ 243.683833][ T123] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000<br /> [ 243.683852][ T123] Call Trace:<br /> [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable)<br /> [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0<br /> [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0<br /> [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210<br /> [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50<br /> [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0<br /> [ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60<br /> [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc<br /> [ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270<br /> [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0<br /> [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0<br /> [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650<br /> [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150<br /> [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340<br /> [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec<br /> ...<br /> [ 243.684087][ T123] Showing all locks held in the system:<br /> [ 243.684095][ T123] 1 lock held by khungtaskd/123:<br /> [ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248<br /> [ 243.684114][ T123] 4 locks held by stress.sh/4365:<br /> [ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150<br /> [ 243.684132][ T123] #1: c000000041aea888 (&amp;of-&gt;mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0<br /> [ 243.684143][ T123] #2: c0000000366fb9a8 (kn-&gt;active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0<br /> [ 243.684155][ T123] #3: c000000035ff4cb8 (&amp;dev-&gt;lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60<br /> [ 243.684166][ T123] 5 locks held by stress.sh/4366:<br /> [ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150<br /> [ 243.<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: BPF: Don&amp;#39;t override subprog&amp;#39;s return value<br /> <br /> The verifier test `calls: div by 0 in subprog` triggers a panic at the<br /> ld.bu instruction. The ld.bu insn is trying to load byte from memory<br /> address returned by the subprog. The subprog actually set the correct<br /> address at the a5 register (dedicated register for BPF return values).<br /> But at commit 73c359d1d356 ("LoongArch: BPF: Sign-extend return values")<br /> we also sign extended a5 to the a0 register (return value in LoongArch).<br /> For function call insn, we later propagate the a0 register back to a5<br /> register. This is right for native calls but wrong for bpf2bpf calls<br /> which expect zero-extended return value in a5 register. So only move a0<br /> to a5 for native calls (i.e. non-BPF_PSEUDO_CALL).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/microcode/AMD: Fix __apply_microcode_amd()&amp;#39;s return value<br /> <br /> When verify_sha256_digest() fails, __apply_microcode_amd() should propagate<br /> the failure by returning false (and not -1 which is promoted to true).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uprobes/x86: Harden uretprobe syscall trampoline check<br /> <br /> Jann reported a possible issue when trampoline_check_ip returns<br /> address near the bottom of the address space that is allowed to<br /> call into the syscall if uretprobes are not set up:<br /> <br /> https://lore.kernel.org/bpf/202502081235.5A6F352985@keescook/T/#m9d416df341b8fbc11737dacbcd29f0054413cbbf<br /> <br /> Though the mmap minimum address restrictions will typically prevent<br /> creating mappings there, let&amp;#39;s make sure uretprobe syscall checks<br /> for that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Increase ARCH_DMA_MINALIGN up to 16<br /> <br /> ARCH_DMA_MINALIGN is 1 by default, but some LoongArch-specific devices<br /> (such as APBDMA) require 16 bytes alignment. When the data buffer length<br /> is too small, the hardware may make an error writing cacheline. Thus, it<br /> is dangerous to allocate a small memory buffer for DMA. It&amp;#39;s always safe<br /> to define ARCH_DMA_MINALIGN as L1_CACHE_BYTES but unnecessary (kmalloc()<br /> need small memory objects). Therefore, just increase it to 16.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet:fix NPE during rx_complete<br /> <br /> Missing usbnet_going_away Check in Critical Path.<br /> The usb_submit_urb function lacks a usbnet_going_away<br /> validation, whereas __usbnet_queue_skb includes this check.<br /> <br /> This inconsistency creates a race condition where:<br /> A URB request may succeed, but the corresponding SKB data<br /> fails to be queued.<br /> <br /> Subsequent processes:<br /> (e.g., rx_complete → defer_bh → __skb_unlink(skb, list))<br /> attempt to access skb-&gt;next, triggering a NULL pointer<br /> dereference (Kernel Panic).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arcnet: Add NULL check in com20020pci_probe()<br /> <br /> devm_kasprintf() returns NULL when memory allocation fails. Currently,<br /> com20020pci_probe() does not check for this case, which results in a<br /> NULL pointer dereference.<br /> <br /> Add NULL check after devm_kasprintf() to prevent this issue and ensure<br /> no resources are left allocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix geneve_opt length integer overflow<br /> <br /> struct geneve_opt uses 5 bit length for each single option, which<br /> means every vary size option should be smaller than 128 bytes.<br /> <br /> However, all current related Netlink policies cannot promise this<br /> length condition and the attacker can exploit a exact 128-byte size<br /> option to *fake* a zero length option and confuse the parsing logic,<br /> further achieve heap out-of-bounds read.<br /> <br /> One example crash log is like below:<br /> <br /> [ 3.905425] ==================================================================<br /> [ 3.905925] BUG: KASAN: slab-out-of-bounds in nla_put+0xa9/0xe0<br /> [ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177<br /> [ 3.906646]<br /> [ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1<br /> [ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> [ 3.907784] Call Trace:<br /> [ 3.907925] <br /> [ 3.908048] dump_stack_lvl+0x44/0x5c<br /> [ 3.908258] print_report+0x184/0x4be<br /> [ 3.909151] kasan_report+0xc5/0x100<br /> [ 3.909539] kasan_check_range+0xf3/0x1a0<br /> [ 3.909794] memcpy+0x1f/0x60<br /> [ 3.909968] nla_put+0xa9/0xe0<br /> [ 3.910147] tunnel_key_dump+0x945/0xba0<br /> [ 3.911536] tcf_action_dump_1+0x1c1/0x340<br /> [ 3.912436] tcf_action_dump+0x101/0x180<br /> [ 3.912689] tcf_exts_dump+0x164/0x1e0<br /> [ 3.912905] fw_dump+0x18b/0x2d0<br /> [ 3.913483] tcf_fill_node+0x2ee/0x460<br /> [ 3.914778] tfilter_notify+0xf4/0x180<br /> [ 3.915208] tc_new_tfilter+0xd51/0x10d0<br /> [ 3.918615] rtnetlink_rcv_msg+0x4a2/0x560<br /> [ 3.919118] netlink_rcv_skb+0xcd/0x200<br /> [ 3.919787] netlink_unicast+0x395/0x530<br /> [ 3.921032] netlink_sendmsg+0x3d0/0x6d0<br /> [ 3.921987] __sock_sendmsg+0x99/0xa0<br /> [ 3.922220] __sys_sendto+0x1b7/0x240<br /> [ 3.922682] __x64_sys_sendto+0x72/0x90<br /> [ 3.922906] do_syscall_64+0x5e/0x90<br /> [ 3.923814] entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> [ 3.924122] RIP: 0033:0x7e83eab84407<br /> [ 3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf<br /> [ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c<br /> [ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407<br /> [ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003<br /> [ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c<br /> [ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0<br /> [ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8<br /> <br /> Fix these issues by enforing correct length condition in related<br /> policies.