Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix RCU stall in bpf_fd_array_map_clear()<br /> <br /> Add a missing cond_resched() in bpf_fd_array_map_clear() loop.<br /> <br /> For PROG_ARRAY maps with many entries this loop calls<br /> prog_array_map_poke_run() per entry which can be expensive, and<br /> without yielding this can cause RCU stalls under load:<br /> <br /> rcu: Stack dump where RCU GP kthread last ran:<br /> CPU: 0 UID: 0 PID: 30932 Comm: kworker/0:2 Not tainted 6.14.0-13195-g967e8def1100 #2 PREEMPT(undef)<br /> Workqueue: events prog_array_map_clear_deferred<br /> RIP: 0010:write_comp_data+0x38/0x90 kernel/kcov.c:246<br /> Call Trace:<br /> <br /> prog_array_map_poke_run+0x77/0x380 kernel/bpf/arraymap.c:1096<br /> __fd_array_map_delete_elem+0x197/0x310 kernel/bpf/arraymap.c:925<br /> bpf_fd_array_map_clear kernel/bpf/arraymap.c:1000 [inline]<br /> prog_array_map_clear_deferred+0x119/0x1b0 kernel/bpf/arraymap.c:1141<br /> process_one_work+0x898/0x19d0 kernel/workqueue.c:3238<br /> process_scheduled_works kernel/workqueue.c:3319 [inline]<br /> worker_thread+0x770/0x10b0 kernel/workqueue.c:3400<br /> kthread+0x465/0x880 kernel/kthread.c:464<br /> ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:153<br /> ret_from_fork_asm+0x19/0x30 arch/x86/entry/entry_64.S:245<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf<br /> <br /> sixpack_receive_buf() does not properly skip bytes with TTY error flags.<br /> The while loop iterates through the flags buffer but never advances the<br /> data pointer (cp), and passes the original count (including error bytes)<br /> to sixpack_decode(). This causes sixpack_decode() to process bytes that<br /> should have been skipped due to TTY errors. The TTY layer does not<br /> guarantee that cp[i] holds a meaningful value when fp[i] is set, so<br /> passing those positions to sixpack_decode() results in KMSAN reporting<br /> an uninit-value read.<br /> <br /> Fix this by processing bytes one at a time, advancing cp on each<br /> iteration, and only passing valid (non-error) bytes to sixpack_decode().<br /> This matches the pattern used by slip_receive_buf() and<br /> mkiss_receive_buf() for the same purpose.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Enforce regsafe base id consistency for BPF_ADD_CONST scalars<br /> <br /> When regsafe() compares two scalar registers that both carry<br /> BPF_ADD_CONST, check_scalar_ids() maps their full compound id<br /> (aka base | BPF_ADD_CONST flag) as one idmap entry. However,<br /> it never verifies that the underlying base ids, that is, with<br /> the flag stripped are consistent with existing idmap mappings.<br /> <br /> This allows construction of two verifier states where the old<br /> state has R3 = R2 + 10 (both sharing base id A) while the current<br /> state has R3 = R4 + 10 (base id C, unrelated to R2). The idmap<br /> creates two independent entries: A-&gt;B (for R2) and A|flag-&gt;C|flag<br /> (for R3), without catching that A-&gt;C conflicts with A-&gt;B. State<br /> pruning then incorrectly succeeds.<br /> <br /> Fix this by additionally verifying base ID mapping consistency<br /> whenever BPF_ADD_CONST is set: after mapping the compound ids,<br /> also invoke check_ids() on the base IDs (flag bits stripped).<br /> This ensures that if A was already mapped to B from comparing<br /> the source register, any ADD_CONST derivative must also derive<br /> from B, not an unrelated C.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: cls_fw: fix NULL dereference of "old" filters before change()<br /> <br /> Like pointed out by Sashiko [1], since commit ed76f5edccc9 ("net: sched:<br /> protect filter_chain list with filter_chain_lock mutex") TC filters are<br /> added to a shared block and published to datapath before their -&gt;change()<br /> function is called. This is a problem for cls_fw: an invalid filter<br /> created with the "old" method can still classify some packets before it<br /> is destroyed by the validation logic added by Xiang.<br /> Therefore, insisting with repeated runs of the following script:<br /> <br /> # ip link add dev crash0 type dummy<br /> # ip link set dev crash0 up<br /> # mausezahn crash0 -c 100000 -P 10 \<br /> &gt; -A 4.3.2.1 -B 1.2.3.4 -t udp "dp=1234" -q &amp;<br /> # sleep 1<br /> # tc qdisc add dev crash0 egress_block 1 clsact<br /> # tc filter add block 1 protocol ip prio 1 matchall \<br /> &gt; action skbedit mark 65536 continue<br /> # tc filter add block 1 protocol ip prio 2 fw<br /> # ip link del dev crash0<br /> <br /> can still make fw_classify() hit the WARN_ON() in [2]:<br /> <br /> WARNING: ./include/net/pkt_cls.h:88 at fw_classify+0x244/0x250 [cls_fw], CPU#18: mausezahn/1399<br /> Modules linked in: cls_fw(E) act_skbedit(E)<br /> CPU: 18 UID: 0 PID: 1399 Comm: mausezahn Tainted: G E 7.0.0-rc6-virtme #17 PREEMPT(full)<br /> Tainted: [E]=UNSIGNED_MODULE<br /> Hardware name: Red Hat KVM, BIOS 1.16.3-2.el9 04/01/2014<br /> RIP: 0010:fw_classify+0x244/0x250 [cls_fw]<br /> Code: 5c 49 c7 45 00 00 00 00 00 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 5b b8 ff ff ff ff 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 90 0b 90 eb a0 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90<br /> RSP: 0018:ffffd1b7026bf8a8 EFLAGS: 00010202<br /> RAX: ffff8c5ac9c60800 RBX: ffff8c5ac99322c0 RCX: 0000000000000004<br /> RDX: 0000000000000001 RSI: ffff8c5b74d7a000 RDI: ffff8c5ac8284f40<br /> RBP: ffffd1b7026bf8d0 R08: 0000000000000000 R09: ffffd1b7026bf9b0<br /> R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000010000<br /> R13: ffffd1b7026bf930 R14: ffff8c5ac8284f40 R15: 0000000000000000<br /> FS: 00007fca40c37740(0000) GS:ffff8c5b74d7a000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fca40e822a0 CR3: 0000000005ca0001 CR4: 0000000000172ef0<br /> Call Trace:<br /> <br /> tcf_classify+0x17d/0x5c0<br /> tc_run+0x9d/0x150<br /> __dev_queue_xmit+0x2ab/0x14d0<br /> ip_finish_output2+0x340/0x8f0<br /> ip_output+0xa4/0x250<br /> raw_sendmsg+0x147d/0x14b0<br /> __sys_sendto+0x1cc/0x1f0<br /> __x64_sys_sendto+0x24/0x30<br /> do_syscall_64+0x126/0xf80<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fca40e822ba<br /> Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89<br /> RSP: 002b:00007ffc248a42c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c<br /> RAX: ffffffffffffffda RBX: 000055ef233289d0 RCX: 00007fca40e822ba<br /> RDX: 000000000000001e RSI: 000055ef23328c30 RDI: 0000000000000003<br /> RBP: 000055ef233289d0 R08: 00007ffc248a42d0 R09: 0000000000000010<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000001e<br /> R13: 00000000000186a0 R14: 0000000000000000 R15: 00007fca41043000<br /> <br /> irq event stamp: 1045778<br /> hardirqs last enabled at (1045784): [] __up_console_sem+0x52/0x60<br /> hardirqs last disabled at (1045789): [] __up_console_sem+0x37/0x60<br /> softirqs last enabled at (1045426): [] __alloc_skb+0x207/0x260<br /> softirqs last disabled at (1045434): [] __dev_queue_xmit+0x78/0x14d0<br /> <br /> Then, because of the value in the packet&amp;#39;s mark, dereference on &amp;#39;q-&gt;handle&amp;#39;<br /> with NULL &amp;#39;q&amp;#39; occurs:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000038<br /> [...]<br /> RIP: 0010:fw_classify+0x1fe/0x250 [cls_fw]<br /> [...]<br /> <br /> Skip "old-style" classification on shared blocks, so that the NULL<br /> dereference is fixed and WARN_ON() is not hit anymore in the short<br /> lifetime of invalid cls_fw "old-style" filters.<br /> <br /> [1] https://sashiko.dev/#/patchset/2<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER<br /> <br /> When protocol sets HCI_PROTO_DEFER, hci_conn_request_evt() calls<br /> hci_connect_cfm(conn) without hdev-&gt;lock. Generally hci_connect_cfm()<br /> assumes it is held, and if conn is deleted concurrently -&gt; UAF.<br /> <br /> Only SCO and ISO set HCI_PROTO_DEFER and only for defer setup listen,<br /> and HCI_EV_CONN_REQUEST is not generated for ISO. In the non-deferred<br /> listening socket code paths, hci_connect_cfm(conn) is called with<br /> hdev-&gt;lock held.<br /> <br /> Fix by holding the lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_ldisc: Clear HCI_UART_PROTO_INIT on error<br /> <br /> When hci_register_dev() fails in hci_uart_register_dev()<br /> HCI_UART_PROTO_INIT is not cleared before calling hu-&gt;proto-&gt;close(hu)<br /> and setting hu-&gt;hdev to NULL. This means incoming UART data will reach<br /> the protocol-specific recv handler in hci_uart_tty_receive() after<br /> resources are freed.<br /> <br /> Clear HCI_UART_PROTO_INIT with a write lock before calling<br /> hu-&gt;proto-&gt;close() and setting hu-&gt;hdev to NULL. The write lock ensures<br /> all active readers have completed and no new reader can enter the<br /> protocol recv path before resources are freed.<br /> <br /> This allows the protocol-specific recv functions to remove the<br /> "HCI_UART_REGISTERED" guard without risking a null pointer dereference<br /> if hci_register_dev() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb<br /> <br /> bpf_prog_test_run_skb() calls eth_type_trans() first and then uses<br /> skb-&gt;protocol to initialize sk family and address fields for the test<br /> run.<br /> <br /> For IPv4 and IPv6 packets, it may access ip_hdr(skb) or ipv6_hdr(skb)<br /> even when the provided test input only contains an Ethernet header.<br /> <br /> Reject the input earlier if the Ethernet frame carries IPv4/IPv6<br /> EtherType but the L3 header is too short.<br /> <br /> Fold the IPv4/IPv6 header length checks into the existing protocol<br /> switch and return -EINVAL before accessing the network headers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ppp: require CAP_NET_ADMIN in target netns for unattached ioctls<br /> <br /> /dev/ppp open is currently authorized against file-&gt;f_cred-&gt;user_ns,<br /> while unattached administrative ioctls operate on current-&gt;nsproxy-&gt;net_ns.<br /> <br /> As a result, a local unprivileged user can create a new user namespace<br /> with CLONE_NEWUSER, gain CAP_NET_ADMIN only in that new user namespace,<br /> and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against<br /> an inherited network namespace.<br /> <br /> Require CAP_NET_ADMIN in the user namespace that owns the target network<br /> namespace before handling unattached PPP administrative ioctls.<br /> <br /> This preserves normal pppd operation in the network namespace it is<br /> actually privileged in, while rejecting the userns-only inherited-netns<br /> case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix OOB in pcpu_init_value<br /> <br /> An out-of-bounds read occurs when copying element from a<br /> BPF_MAP_TYPE_CGROUP_STORAGE map to another pcpu map with the<br /> same value_size that is not rounded up to 8 bytes.<br /> <br /> The issue happens when:<br /> 1. A CGROUP_STORAGE map is created with value_size not aligned to<br /> 8 bytes (e.g., 4 bytes)<br /> 2. A pcpu map is created with the same value_size (e.g., 4 bytes)<br /> 3. Update element in 2 with data in 1<br /> <br /> pcpu_init_value assumes that all sources are rounded up to 8 bytes,<br /> and invokes copy_map_value_long to make a data copy, However, the<br /> assumption doesn&amp;#39;t stand since there are some cases where the source<br /> may not be rounded up to 8 bytes, e.g., CGROUP_STORAGE, skb-&gt;data.<br /> the verifier verifies exactly the size that the source claims, not<br /> the size rounded up to 8 bytes by kernel, an OOB happens when the<br /> source has only 4 bytes while the copy size(4) is rounded up to 8.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rds: Restrict use of RDS/IB to the initial network namespace<br /> <br /> Prevent using RDS/IB in network namespaces other than the initial one.<br /> The existing RDS/IB code will not work properly in non-initial network<br /> namespaces.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops<br /> <br /> When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg,<br /> the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the<br /> destination register in the !fullsock / !locked_tcp_sock path.<br /> <br /> Both macros borrow a temporary register to check is_fullsock /<br /> is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the<br /> ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with<br /> a request_sock), dst_reg should be zeroed but is not, leaving the stale<br /> ctx pointer:<br /> <br /> - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks<br /> as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer,<br /> leading to stack-out-of-bounds access in helpers like<br /> bpf_skc_to_tcp6_sock().<br /> <br /> - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the<br /> verifier believes is a SCALAR_VALUE, leaking a kernel pointer.<br /> <br /> Fix both macros by:<br /> - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the<br /> added instruction.<br /> - Adding BPF_MOV64_IMM(si-&gt;dst_reg, 0) after the temp register<br /> restore in the !fullsock path, placed after the restore because<br /> dst_reg == src_reg means we need src_reg intact to read ctx-&gt;temp.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: fix skb memory leak in deferred qdisc drops<br /> <br /> When the network stack cleans up the deferred list via qdisc_run_end(),<br /> it operates on the root qdisc. If the root qdisc do not implement the<br /> TCQ_F_DEQUEUE_DROPS flag the packets queue to free are never freed and<br /> gets stranded on the child&amp;#39;s local to_free list.<br /> <br /> Fix this by making qdisc_dequeue_drop() aware of the root qdisc. It<br /> fetches the root qdisc and check for the TCQ_F_DEQUEUE_DROPS flag. If<br /> the flag is present, the packet is appended directly to the root&amp;#39;s<br /> to_free list. Otherwise, drop it directly as it was done before the<br /> optimization was implemented.