Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master<br /> <br /> syzkaller reported a kernel panic in bond_rr_gen_slave_id() reached via<br /> xdp_master_redirect(). Full decoded trace:<br /> <br /> https://syzkaller.appspot.com/bug?extid=80e046b8da2820b6ba73<br /> <br /> bond_rr_gen_slave_id() dereferences bond-&gt;rr_tx_counter, a per-CPU<br /> counter that bonding only allocates in bond_open() when the mode is<br /> round-robin. If the bond device was never brought up, rr_tx_counter<br /> stays NULL.<br /> <br /> The XDP redirect path can still reach that code on a bond that was<br /> never opened: bpf_master_redirect_enabled_key is a global static key,<br /> so as soon as any bond device has native XDP attached, the<br /> XDP_TX -&gt; xdp_master_redirect() interception is enabled for every<br /> slave system-wide. The path xdp_master_redirect() -&gt;<br /> bond_xdp_get_xmit_slave() -&gt; bond_xdp_xmit_roundrobin_slave_get() -&gt;<br /> bond_rr_gen_slave_id() then runs against a bond that has no<br /> rr_tx_counter and crashes.<br /> <br /> Fix this in the generic xdp_master_redirect() by refusing to call into<br /> the master&amp;#39;s -&gt;ndo_xdp_get_xmit_slave() when the master device is not<br /> up. IFF_UP is only set after -&gt;ndo_open() has successfully returned,<br /> so this reliably excludes masters whose XDP state has not been fully<br /> initialized. Drop the frame with XDP_ABORTED so the exception is<br /> visible via trace_xdp_exception() rather than silently falling through.<br /> This is not specific to bonding: any current or future master that<br /> defers XDP state allocation to -&gt;ndo_open() is protected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: disable BH before calling udp_tunnel_xmit_skb()<br /> <br /> udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with<br /> BH disabled. After commit 6f1a9140ecda ("add xmit recursion limit to<br /> tunnel xmit functions"), on the path:<br /> <br /> udp(6)_tunnel_xmit_skb() -&gt; ip(6)tunnel_xmit()<br /> <br /> dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU.<br /> <br /> Without local_bh_disable(), the context may move between CPUs, which can<br /> break the inc/dec pairing. This may lead to incorrect recursion level<br /> detection and cause packets to be dropped in ip(6)_tunnel_xmit() or<br /> __dev_queue_xmit().<br /> <br /> Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths.<br /> <br /> In my testing, after enabling the SCTP over UDP:<br /> <br /> # ip net exec ha sysctl -w net.sctp.udp_port=9899<br /> # ip net exec ha sysctl -w net.sctp.encap_port=9899<br /> # ip net exec hb sysctl -w net.sctp.udp_port=9899<br /> # ip net exec hb sysctl -w net.sctp.encap_port=9899<br /> <br /> # ip net exec ha iperf3 -s<br /> <br /> - without this patch:<br /> <br /> # ip net exec hb iperf3 -c 192.168.0.1 --sctp<br /> [ 5] 0.00-10.00 sec 37.2 MBytes 31.2 Mbits/sec sender<br /> [ 5] 0.00-10.00 sec 37.1 MBytes 31.1 Mbits/sec receiver<br /> <br /> - with this patch:<br /> <br /> # ip net exec hb iperf3 -c 192.168.0.1 --sctp<br /> [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec sender<br /> [ 5] 0.00-10.00 sec 3.14 GBytes 2.69 Gbits/sec receiver

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp<br /> <br /> l2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding<br /> l2cap_chan_lock(). Every other l2cap_chan_del() caller in the file<br /> acquires the lock first. A remote BLE device can send a crafted<br /> L2CAP ECRED reconfiguration response to corrupt the channel list<br /> while another thread is iterating it.<br /> <br /> Add l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(),<br /> and l2cap_chan_unlock() and l2cap_chan_put() after, matching the<br /> pattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del().