Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: slip: serialize receive against buffer reallocation<br /> <br /> sl_realloc_bufs() replaces rbuff and updates buffsize while holding<br /> sl-&gt;lock. slip_receive_buf() reads those fields and writes through rbuff<br /> without holding the lock.<br /> <br /> An MTU change can therefore race with receive processing. An MTU shrink<br /> can expose the new smaller rbuff with the old larger bound, causing an<br /> out-of-bounds write. A receive callback which already loaded the old<br /> rbuff can instead continue writing after that buffer has been freed.<br /> <br /> Serialize receive processing with sl_realloc_bufs() by holding sl-&gt;lock<br /> while consuming each receive batch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phonet: pep: fix use-after-free in pep_get_sb()<br /> <br /> pep_get_sb() doesn&amp;#39;t consider that pskb_may_pull() might have relocated<br /> the skb data, and continue to access the older pointer, causing UAF.<br /> <br /> Reproduced under KASAN:<br /> <br /> BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0<br /> Read of size 1 at addr ff11000105510f50 by task repro/157<br /> pep_get_sb+0x234/0x3b0<br /> pipe_handler_do_rcv+0x5f7/0xa10<br /> pep_do_rcv+0x203/0x410<br /> __sk_receive_skb+0x471/0x4a0<br /> phonet_rcv+0x5b3/0x6c0<br /> __netif_receive_skb+0xcc/0x1d0<br /> <br /> Refetch the header with skb_header_pointer() after pskb_may_pull(), so<br /> the possibly stale pointer is no longer dereferenced. There are better<br /> ways to solve this, but, this is the less instrusive one.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Add global mutex to serialize trace_parser access<br /> <br /> In ftrace, the trace_parser structure is allocated and initialized when<br /> a trace file is opened, and is subsequently used across write and release<br /> handlers to parse user input.<br /> <br /> The affected handler paths and their specific functions are:<br /> - Open paths: ftrace_regex_open(), ftrace_graph_open()<br /> - Write paths: ftrace_regex_write(), ftrace_graph_write()<br /> - Release paths: ftrace_regex_release(), ftrace_graph_release()<br /> <br /> If userspace opens a trace file descriptor and shares it across multiple<br /> threads, concurrent write calls will race on the parser&amp;#39;s internal state,<br /> specifically the &amp;#39;idx&amp;#39;, &amp;#39;cont&amp;#39;, and &amp;#39;buffer&amp;#39; fields, leading to corrupted<br /> input or undefined behavior.<br /> <br /> Fix this by adding a global mutex, parser_lock, to serialize all access<br /> to trace_parser across write and release paths, preventing concurrent<br /> corruption of parser state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fscrypt: Avoid dynamic allocation in fscrypt_get_devices()<br /> <br /> When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls<br /> fscrypt_get_devices() to get the filesystem&amp;#39;s list of block devices,<br /> then iterates over them and calls blk_crypto_config_supported(),<br /> blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one.<br /> <br /> Currently, the block device pointers are placed in a dynamically<br /> allocated array. This dynamic allocation is problematic because:<br /> <br /> - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call<br /> site when it&amp;#39;s invoked for inode eviction under direct reclaim.<br /> <br /> - fscrypt_destroy_inline_crypt_key() doesn&amp;#39;t handle the failure. It<br /> just zeroizes and frees the blk_crypto_key without calling<br /> blk_crypto_evict_key(). That causes a use-after-free.<br /> <br /> For now, let&amp;#39;s fix this in the straightforward and easily-backportable<br /> way by switching to an on-stack array. Currently the fscrypt<br /> multi-device functionality is used only by f2fs, which has a hardcoded<br /> limit of 8 block devices. An on-stack array works fine for that.<br /> <br /> (Of course, this solution won&amp;#39;t scale up to large number of block<br /> devices. For that we&amp;#39;d need a different solution, like moving the block<br /> device iteration into the filesystem. Or in the case of btrfs, which<br /> will only support blk-crypto-fallback, we should make it just call<br /> blk-crypto-fallback directly, so the block devices won&amp;#39;t be needed.)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fscrypt: Add missing superblock check in find_or_insert_direct_key()<br /> <br /> The legacy &amp;#39;fscrypt_direct_keys&amp;#39; table caches master keys that are used<br /> by v1 encryption policies that have FSCRYPT_POLICY_FLAG_DIRECT_KEY.<br /> It&amp;#39;s just a global table for all filesystems (since the keys can be<br /> provided by the legacy process-subscribed keyrings mechanism, which<br /> makes it difficult to reuse super_block::s_master_keys).<br /> <br /> The entries in it (&amp;#39;struct fscrypt_direct_key&amp;#39;) do contain a super_block<br /> pointer, though, for passing to fscrypt_destroy_inline_crypt_key() when<br /> the last inode that references the key is evicted.<br /> <br /> However, when finding the fscrypt_direct_key for an inode, we weren&amp;#39;t<br /> actually comparing the super_block pointer. As a result, inodes with<br /> different super_blocks could point to the same fscrypt_direct_key. That<br /> could extend the lifetime of a fscrypt_direct_key beyond the<br /> super_block it points to, causing a use-after-free later.<br /> <br /> Fix this by creating distinct fscrypt_direct_key structs for distinct<br /> super_block structs.<br /> <br /> Note that this problem doesn&amp;#39;t exist in the v2 policy equivalent<br /> ("per-mode keys"), since the data structures there are per super_block.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: gro: fix double aggregation of flush-marked skbs<br /> <br /> Commit 0ab03f353d36 ("net-gro: Fix GRO flush when receiving a GSO<br /> packet.") added a flush check to skb_gro_receive(), but<br /> skb_gro_receive_list() lacks the same validation.<br /> <br /> As a result, packets marked with NAPI_GRO_CB(skb)-&gt;flush may still be<br /> re-aggregated.<br /> <br /> This allows already-GRO&amp;#39;d packets with existing frag_list to be<br /> re-aggregated into a new GRO session, corrupting the frag_list chain<br /> structure. When skb_segment() attempts to unpack these malformed packets,<br /> it encounters invalid state and triggers a kernel panic.<br /> <br /> Scenario (Tethering/Device forwarding):<br /> 1. Driver: Generated aggregated packet P1 via LRO with frag_list<br /> 2. Dev A: Receives aggregated fraglist packet and flush flag set<br /> 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called<br /> 4. Missing flush check allows re-aggregation despite flush flag<br /> 5. Frag_list chain becomes corrupted (loops or dangling refs)<br /> 6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list<br /> <br /> Root cause in skb_segment():<br /> The check at line ~4891:<br /> if (hsize = nfrags &amp;&amp; skb_headlen(list_skb) &amp;&amp;<br /> (skb_headlen(list_skb) == len || sg)) {<br /> <br /> When frag_list is corrupted by double aggregation, when list_skb is<br /> a NULL pointer from skb-&gt;next, skb_headlen(list_skb) dereference<br /> NULL/corrupted pointers occurs.<br /> <br /> Call Trace:<br /> skb_headlen(NULL skb)<br /> skb_segment<br /> tcp_gso_segment<br /> tcp4_gso_segment<br /> inet_gso_segment<br /> skb_mac_gso_segment<br /> __skb_gso_segment<br /> skb_gso_segment<br /> validate_xmit_skb<br /> validate_xmit_skb_list<br /> sch_direct_xmit<br /> qdisc_restart<br /> __qdisc_run<br /> qdisc_run<br /> net_tx_action<br /> <br /> Fix: Add NAPI_GRO_CB(skb)-&gt;flush validation to the early-return check in<br /> skb_gro_receive_list(), matching the defensive programming pattern of<br /> skb_gro_receive().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: serialize qdisc_rtab_list against concurrent get/put<br /> <br /> qdisc_get_rtab() and qdisc_put_rtab() mutate the process-global singly<br /> linked list qdisc_rtab_list and a plain non-atomic &amp;#39;int refcnt&amp;#39; with no<br /> lock. This was only safe because every caller historically held the RTNL<br /> mutex, which serialized all rate-table lookups, inserts and frees.<br /> <br /> That invariant no longer holds. cls_flower sets<br /> TCF_PROTO_OPS_DOIT_UNLOCKED, so tc_new_tfilter() keeps rtnl_held == false<br /> for it and sets TCA_ACT_FLAGS_NO_RTNL. That flag propagates through<br /> tcf_exts_validate_ex() -&gt; tcf_action_init() -&gt; tcf_action_init_1() -&gt;<br /> tcf_police_init(), which calls qdisc_get_rtab()/qdisc_put_rtab() with the<br /> RTNL mutex NOT held. Two RTM_NEWTFILTER requests on different CPUs, each<br /> adding a flower filter with a police action carrying the same rate, then<br /> race on qdisc_rtab_list and on the non-atomic refcnt, leading to a<br /> use-after-free / double-free of the kmalloc-2k struct qdisc_rate_table.<br /> qdisc_rtab_list is a single global (not per-netns), so the corrupted<br /> object is shared system-wide.<br /> <br /> BUG: KASAN: slab-use-after-free in qdisc_put_rtab+0x12f/0x160<br /> qdisc_put_rtab+0x12f/0x160<br /> tcf_police_init+0xda9/0x1590<br /> tcf_action_init_1+0x460/0x6b0<br /> tcf_action_init+0x439/0xa40<br /> tcf_exts_validate_ex+0x42d/0x550<br /> fl_change+0xddd/0x7da0<br /> tc_new_tfilter+0xaa7/0x2420<br /> rtnetlink_rcv_msg+0x95e/0xe90<br /> which belongs to the cache kmalloc-2k of size 2048<br /> <br /> Protect qdisc_rtab_list and the refcount with a dedicated spinlock. The<br /> (sleeping, GFP_KERNEL) allocation in qdisc_get_rtab() is performed before<br /> taking the lock; if a concurrent inserter added an identical table in the<br /> meantime the freshly allocated one is freed under the lock, so no<br /> duplicate is leaked. qdisc_put_rtab() now decrements the refcount and<br /> unlinks under the same lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Use sender devcom for MPV master-up<br /> <br /> After PCIe DPC recovery, mlx5 reloads the affected functions and<br /> replays multiport affiliation events. In the reported failure, the<br /> first relevant device error was:<br /> <br /> pcieport 0000:10:01.1: DPC: containment event<br /> pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal)<br /> pcieport 0000:10:01.1: [ 5] SDES (First)<br /> <br /> mlx5 recovered the PCI functions and resumed 0000:11:00.1. During<br /> that resume, RDMA multiport binding replayed<br /> MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent<br /> MPV_DEVCOM_MASTER_UP. The host then panicked with:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core]<br /> RDI: 0000000000000000<br /> <br /> Call trace included:<br /> <br /> mlx5_devcom_comp_set_ready<br /> mlx5e_devcom_event_mpv<br /> mlx5_devcom_send_event<br /> mlx5_ib_bind_slave_port<br /> mlx5r_mp_probe<br /> mlx5_pci_resume<br /> <br /> MPV devcom registration publishes mlx5e private data to the component<br /> peer list before mlx5e_devcom_init_mpv() stores the returned component<br /> device in priv-&gt;devcom. A concurrent master-up event can therefore<br /> reach a peer whose private data is visible but whose priv-&gt;devcom<br /> backpointer is still NULL.<br /> <br /> MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private<br /> data as event_data. The ready bit is stored on the shared devcom<br /> component, not on an individual peer. Use the sender devcom when<br /> marking the MPV component ready.<br /> <br /> This preserves the readiness transition while avoiding a NULL<br /> dereference of the peer devcom pointer during affiliation replay after<br /> PCI error recovery.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/x25: fix use-after-free in x25_kill_by_neigh()<br /> <br /> x25_kill_by_neigh() walks the global X.25 socket list looking for sockets<br /> attached to a terminating neighbour. x25_list_lock protects list membership<br /> while the lookup is in progress, but it does not pin a socket&amp;#39;s lifetime<br /> after the lock is dropped.<br /> <br /> The function currently drops x25_list_lock before calling lock_sock(s). A<br /> concurrent close can run x25_release(), remove the same socket from<br /> x25_list, and drop the last socket reference in that window. The neighbour<br /> teardown path can then lock or inspect a freed struct sock/struct x25_sock.<br /> <br /> Take sock_hold(s) while x25_list_lock still proves that the list entry is<br /> live, then drop the temporary reference after the socket has been locked,<br /> rechecked, and released. Recheck x25_sk(s)-&gt;neighbour after lock_sock(),<br /> because another path may have disconnected the socket before this path<br /> acquired the socket lock. Restart the list walk after each disconnect<br /> because the list lock was dropped and the previous iterator state may no<br /> longer be valid.<br /> <br /> A QEMU/KASAN run against origin/master reproduced a slab-use-after-free in<br /> x25_kill_by_neigh().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/iucv: fix use-after-free of a severed iucv_path<br /> <br /> af_iucv queues not-yet-received message notifications on iucv-&gt;message_q,<br /> each holding a raw pointer to the connection&amp;#39;s iucv_path. When the peer<br /> severs the connection, iucv_sever_path() frees that path with<br /> iucv_path_free() but leaves the notifications queued. A later recvmsg()<br /> drains message_q via iucv_process_message_q() and hands the stale path to<br /> message_receive() -- a use-after-free of the freed iucv_path.<br /> <br /> Drop the queued notifications when the path is severed; once the path is<br /> gone they can no longer be received. This also frees the notifications<br /> leaked when a socket is closed with messages still queued.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/af_iucv: fix NULL deref in afiucv_hs_callback_syn()<br /> <br /> afiucv_hs_callback_syn() allocates the child socket with GFP_ATOMIC.<br /> If the allocation fails, nsk is NULL.<br /> <br /> The connection-refused path is entered when the listen state check<br /> fails, the accept backlog is full, or nsk is NULL. The code<br /> unconditionally calls iucv_sock_kill(nsk) in that path.<br /> <br /> iucv_sock_kill() does not accept a NULL socket pointer and immediately<br /> dereferences sk via sock_flag(sk, SOCK_ZAPPED). When nsk is NULL,<br /> calling iucv_sock_kill(nsk) results in a NULL pointer dereference.<br /> <br /> Only call iucv_sock_kill() when a child socket was successfully<br /> allocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> geneve: require CAP_NET_ADMIN in the device netns for changelink<br /> <br /> A tunnel changelink() operates on at most two netns, dev_net(dev) and<br /> the sticky underlay netns geneve-&gt;net. They differ once the device is<br /> created in or moved to a netns other than the one the request runs in.<br /> The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev),<br /> so a caller privileged there but not in geneve-&gt;net can rewrite a geneve<br /> device whose underlay lives in geneve-&gt;net.<br /> <br /> geneve_changelink() applies the new configuration against geneve-&gt;net:<br /> geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair<br /> reopen the underlay sockets in that netns (geneve_sock_add() uses<br /> geneve-&gt;net), so the same reasoning as the tunnel changelink series<br /> applies here.<br /> <br /> Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of<br /> the op before any attribute is parsed, matching ipgre_changelink() and<br /> the rest of the "require CAP_NET_ADMIN in the device netns for<br /> changelink" series.<br /> <br /> Found by 0sec automated security-research tooling (https://0sec.ai).