Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_api: avoid dereferencing ERR_PTR in tcf_idrinfo_destroy<br /> <br /> syzbot reported a crash in tc_act_in_hw() during netns teardown where<br /> tcf_idrinfo_destroy() passed an ERR_PTR(-EBUSY) value as a tc_action<br /> pointer, leading to an invalid dereference.<br /> <br /> Guard against ERR_PTR entries when iterating the action IDR so teardown<br /> does not call tc_act_in_hw() on an error pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arp: do not assume dev_hard_header() does not change skb-&gt;head<br /> <br /> arp_create() is the only dev_hard_header() caller<br /> making assumption about skb-&gt;head being unchanged.<br /> <br /> A recent commit broke this assumption.<br /> <br /> Initialize @arp pointer after dev_hard_header() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: check that server is running in unlock_filesystem<br /> <br /> If we are trying to unlock the filesystem via an administrative<br /> interface and nfsd isn&amp;#39;t running, it crashes the server. This<br /> happens currently because nfsd4_revoke_states() access state<br /> structures (eg., conf_id_hashtbl) that has been freed as a part<br /> of the server shutdown.<br /> <br /> [ 59.465072] Call trace:<br /> [ 59.465308] nfsd4_revoke_states+0x1b4/0x898 [nfsd] (P)<br /> [ 59.465830] write_unlock_fs+0x258/0x440 [nfsd]<br /> [ 59.466278] nfsctl_transaction_write+0xb0/0x120 [nfsd]<br /> [ 59.466780] vfs_write+0x1f0/0x938<br /> [ 59.467088] ksys_write+0xfc/0x1f8<br /> [ 59.467395] __arm64_sys_write+0x74/0xb8<br /> [ 59.467746] invoke_syscall.constprop.0+0xdc/0x1e8<br /> [ 59.468177] do_el0_svc+0x154/0x1d8<br /> [ 59.468489] el0_svc+0x40/0xe0<br /> [ 59.468767] el0t_64_sync_handler+0xa0/0xe8<br /> [ 59.469138] el0t_64_sync+0x1ac/0x1b0<br /> <br /> Ensure this can&amp;#39;t happen by taking the nfsd_mutex and checking that<br /> the server is still up, and then holding the mutex across the call to<br /> nfsd4_revoke_states().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm-verity: disable recursive forward error correction<br /> <br /> There are two problems with the recursive correction:<br /> <br /> 1. It may cause denial-of-service. In fec_read_bufs, there is a loop that<br /> has 253 iterations. For each iteration, we may call verity_hash_for_block<br /> recursively. There is a limit of 4 nested recursions - that means that<br /> there may be at most 253^4 (4 billion) iterations. Red Hat QE team<br /> actually created an image that pushes dm-verity to this limit - and this<br /> image just makes the udev-worker process get stuck in the &amp;#39;D&amp;#39; state.<br /> <br /> 2. It doesn&amp;#39;t work. In fec_read_bufs we store data into the variable<br /> "fio-&gt;bufs", but fio bufs is shared between recursive invocations, if<br /> "verity_hash_for_block" invoked correction recursively, it would<br /> overwrite partially filled fio-&gt;bufs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: avoid kernel-infoleak from struct iw_point<br /> <br /> struct iw_point has a 32bit hole on 64bit arches.<br /> <br /> struct iw_point {<br /> void __user *pointer; /* Pointer to the data (in user space) */<br /> __u16 length; /* number of fields or size in bytes */<br /> __u16 flags; /* Optional params */<br /> };<br /> <br /> Make sure to zero the structure to avoid disclosing 32bits of kernel data<br /> to user space.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix memory leak in skb_segment_list for GRO packets<br /> <br /> When skb_segment_list() is called during packet forwarding, it handles<br /> packets that were aggregated by the GRO engine.<br /> <br /> Historically, the segmentation logic in skb_segment_list assumes that<br /> individual segments are split from a parent SKB and may need to carry<br /> their own socket memory accounting. Accordingly, the code transfers<br /> truesize from the parent to the newly created segments.<br /> <br /> Prior to commit ed4cccef64c1 ("gro: fix ownership transfer"), this<br /> truesize subtraction in skb_segment_list() was valid because fragments<br /> still carry a reference to the original socket.<br /> <br /> However, commit ed4cccef64c1 ("gro: fix ownership transfer") changed<br /> this behavior by ensuring that fraglist entries are explicitly<br /> orphaned (skb-&gt;sk = NULL) to prevent illegal orphaning later in the<br /> stack. This change meant that the entire socket memory charge remained<br /> with the head SKB, but the corresponding accounting logic in<br /> skb_segment_list() was never updated.<br /> <br /> As a result, the current code unconditionally adds each fragment&amp;#39;s<br /> truesize to delta_truesize and subtracts it from the parent SKB. Since<br /> the fragments are no longer charged to the socket, this subtraction<br /> results in an effective under-count of memory when the head is freed.<br /> This causes sk_wmem_alloc to remain non-zero, preventing socket<br /> destruction and leading to a persistent memory leak.<br /> <br /> The leak can be observed via KMEMLEAK when tearing down the networking<br /> environment:<br /> <br /> unreferenced object 0xffff8881e6eb9100 (size 2048):<br /> comm "ping", pid 6720, jiffies 4295492526<br /> backtrace:<br /> kmem_cache_alloc_noprof+0x5c6/0x800<br /> sk_prot_alloc+0x5b/0x220<br /> sk_alloc+0x35/0xa00<br /> inet6_create.part.0+0x303/0x10d0<br /> __sock_create+0x248/0x640<br /> __sys_socket+0x11b/0x1d0<br /> <br /> Since skb_segment_list() is exclusively used for SKB_GSO_FRAGLIST<br /> packets constructed by GRO, the truesize adjustment is removed.<br /> <br /> The call to skb_release_head_state() must be preserved. As documented in<br /> commit cf673ed0e057 ("net: fix fraglist segmentation reference count<br /> leak"), it is still required to correctly drop references to SKB<br /> extensions that may be overwritten during __copy_skb_header().

An unauthenticated information disclosure vulnerability in Newgen OmniApp allows attackers to enumerate valid privileged usernames via a publicly accessible client-side JavaScript resource.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: mpsse: ensure worker is torn down<br /> <br /> When an IRQ worker is running, unplugging the device would cause a<br /> crash. The sealevel hardware this driver was written for was not<br /> hotpluggable, so I never realized it.<br /> <br /> This change uses a spinlock to protect a list of workers, which<br /> it tears down on disconnect.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix use-after-free warning in btrfs_get_or_create_delayed_node()<br /> <br /> Previously, btrfs_get_or_create_delayed_node() set the delayed_node&amp;#39;s<br /> refcount before acquiring the root-&gt;delayed_nodes lock.<br /> Commit e8513c012de7 ("btrfs: implement ref_tracker for delayed_nodes")<br /> moved refcount_set inside the critical section, which means there is<br /> no longer a memory barrier between setting the refcount and setting<br /> btrfs_inode-&gt;delayed_node.<br /> <br /> Without that barrier, the stores to node-&gt;refs and<br /> btrfs_inode-&gt;delayed_node may become visible out of order. Another<br /> thread can then read btrfs_inode-&gt;delayed_node and attempt to<br /> increment a refcount that hasn&amp;#39;t been set yet, leading to a<br /> refcounting bug and a use-after-free warning.<br /> <br /> The fix is to move refcount_set back to where it was to take<br /> advantage of the implicit memory barrier provided by lock<br /> acquisition.<br /> <br /> Because the allocations now happen outside of the lock&amp;#39;s critical<br /> section, they can use GFP_NOFS instead of GFP_ATOMIC.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: avoid chain re-validation if possible<br /> <br /> Hamza Mahfooz reports cpu soft lock-ups in<br /> nft_chain_validate():<br /> <br /> watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547]<br /> [..]<br /> RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables]<br /> [..]<br /> nft_immediate_validate+0x36/0x50 [nf_tables]<br /> nft_chain_validate+0xc9/0x110 [nf_tables]<br /> nft_immediate_validate+0x36/0x50 [nf_tables]<br /> nft_chain_validate+0xc9/0x110 [nf_tables]<br /> nft_immediate_validate+0x36/0x50 [nf_tables]<br /> nft_chain_validate+0xc9/0x110 [nf_tables]<br /> nft_immediate_validate+0x36/0x50 [nf_tables]<br /> nft_chain_validate+0xc9/0x110 [nf_tables]<br /> nft_immediate_validate+0x36/0x50 [nf_tables]<br /> nft_chain_validate+0xc9/0x110 [nf_tables]<br /> nft_immediate_validate+0x36/0x50 [nf_tables]<br /> nft_chain_validate+0xc9/0x110 [nf_tables]<br /> nft_table_validate+0x6b/0xb0 [nf_tables]<br /> nf_tables_validate+0x8b/0xa0 [nf_tables]<br /> nf_tables_commit+0x1df/0x1eb0 [nf_tables]<br /> [..]<br /> <br /> Currently nf_tables will traverse the entire table (chain graph), starting<br /> from the entry points (base chains), exploring all possible paths<br /> (chain jumps). But there are cases where we could avoid revalidation.<br /> <br /> Consider:<br /> 1 input -&gt; j2 -&gt; j3<br /> 2 input -&gt; j2 -&gt; j3<br /> 3 input -&gt; j1 -&gt; j2 -&gt; j3<br /> <br /> Then the second rule does not need to revalidate j2, and, by extension j3,<br /> because this was already checked during validation of the first rule.<br /> We need to validate it only for rule 3.<br /> <br /> This is needed because chain loop detection also ensures we do not exceed<br /> the jump stack: Just because we know that j2 is cycle free, its last jump<br /> might now exceed the allowed stack size. We also need to update all<br /> reachable chains with the new largest observed call depth.<br /> <br /> Care has to be taken to revalidate even if the chain depth won&amp;#39;t be an<br /> issue: chain validation also ensures that expressions are not called from<br /> invalid base chains. For example, the masquerade expression can only be<br /> called from NAT postrouting base chains.<br /> <br /> Therefore we also need to keep record of the base chain context (type,<br /> hooknum) and revalidate if the chain becomes reachable from a different<br /> hook location.

A signed integer overflow in docopt.cpp v0.6.2 (LeafPattern::match in docopt_private.h) when merging occurrence counters (e.g., default LONG_MAX + first user "-v/--verbose") can cause counter wrap (negative/unbounded semantics) and lead to logic/policy bypass in applications that rely on occurrence-based limits, rate-gating, or safety toggles. In hardened builds (e.g., UBSan or -ftrapv), the overflow may also result in process abort (DoS).

An issue was discovered in Free5gc NRF 1.4.0. In the access-token generation logic of free5GC, the AccessTokenScopeCheck() function in file internal/sbi/processor/access_token.go bypasses all scope validation when the attacker uses a crafted targetNF value. This allows attackers to obtain an access token with any arbitrary scope.