Vulnerabilities

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).

Null pointer dereference in free5gc pcf 1.4.0 in file internal/sbi/processor/ampolicy.go in function HandleDeletePoliciesPolAssoId.

A TOCTOU and symlink race in svenstaro/miniserve 0.32.0 upload finalization (when uploads are enabled) can allow an attacker to overwrite arbitrary files outside the intended upload/document root in deployments where the attacker can create/replace filesystem entries in the upload destination directory (e.g., shared writable directory/volume).

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.

Missing Authorization vulnerability in Syed Balkhi Sugar Calendar (Lite) sugar-calendar-lite allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Sugar Calendar (Lite): from n/a through

Authorization Bypass Through User-Controlled Key vulnerability in Rustaurius Ultimate Reviews ultimate-reviews allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Ultimate Reviews: from n/a through