Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: do not write to msg_get_inq in callee<br /> <br /> NULL pointer dereference fix.<br /> <br /> msg_get_inq is an input field from caller to callee. Don&amp;#39;t set it in<br /> the callee, as the caller may not clear it on struct reuse.<br /> <br /> This is a kernel-internal variant of msghdr only, and the only user<br /> does reinitialize the field. So this is not critical for that reason.<br /> But it is more robust to avoid the write, and slightly simpler code.<br /> And it fixes a bug, see below.<br /> <br /> Callers set msg_get_inq to request the input queue length to be<br /> returned in msg_inq. This is equivalent to but independent from the<br /> SO_INQ request to return that same info as a cmsg (tp-&gt;recvmsg_inq).<br /> To reduce branching in the hot path the second also sets the msg_inq.<br /> That is WAI.<br /> <br /> This is a fix to commit 4d1442979e4a ("af_unix: don&amp;#39;t post cmsg for<br /> SO_INQ unless explicitly asked for"), which fixed the inverse.<br /> <br /> Also avoid NULL pointer dereference in unix_stream_read_generic if<br /> state-&gt;msg is NULL and msg-&gt;msg_get_inq is written. A NULL state-&gt;msg<br /> can happen when splicing as of commit 2b514574f7e8 ("net: af_unix:<br /> implement splice for stream af_unix sockets").<br /> <br /> Also collapse two branches using a bitwise or.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpiolib: fix race condition for gdev-&gt;srcu<br /> <br /> If two drivers were calling gpiochip_add_data_with_key(), one may be<br /> traversing the srcu-protected list in gpio_name_to_desc(), meanwhile<br /> other has just added its gdev in gpiodev_add_to_list_unlocked().<br /> This creates a non-mutexed and non-protected timeframe, when one<br /> instance is dereferencing and using &amp;gdev-&gt;srcu, before the other<br /> has initialized it, resulting in crash:<br /> <br /> [ 4.935481] Unable to handle kernel paging request at virtual address ffff800272bcc000<br /> [ 4.943396] Mem abort info:<br /> [ 4.943400] ESR = 0x0000000096000005<br /> [ 4.943403] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 4.943407] SET = 0, FnV = 0<br /> [ 4.943410] EA = 0, S1PTW = 0<br /> [ 4.943413] FSC = 0x05: level 1 translation fault<br /> [ 4.943416] Data abort info:<br /> [ 4.943418] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000<br /> [ 4.946220] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 4.955261] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 4.955268] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000038e6c000<br /> [ 4.961449] [ffff800272bcc000] pgd=0000000000000000<br /> [ 4.969203] , p4d=1000000039739003<br /> [ 4.979730] , pud=0000000000000000<br /> [ 4.980210] phandle (CPU): 0x0000005e, phandle (BE): 0x5e000000 for node "reset"<br /> [ 4.991736] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> ...<br /> [ 5.121359] pc : __srcu_read_lock+0x44/0x98<br /> [ 5.131091] lr : gpio_name_to_desc+0x60/0x1a0<br /> [ 5.153671] sp : ffff8000833bb430<br /> [ 5.298440]<br /> [ 5.298443] Call trace:<br /> [ 5.298445] __srcu_read_lock+0x44/0x98<br /> [ 5.309484] gpio_name_to_desc+0x60/0x1a0<br /> [ 5.320692] gpiochip_add_data_with_key+0x488/0xf00<br /> 5.946419] ---[ end trace 0000000000000000 ]---<br /> <br /> Move initialization code for gdev fields before it is added to<br /> gpio_devices, with adjacent initialization code.<br /> Adjust goto statements to reflect modified order of operations<br /> <br /> [Bartosz: fixed a build issue, removed stray newline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: provide locking for v4_end_grace<br /> <br /> Writing to v4_end_grace can race with server shutdown and result in<br /> memory being accessed after it was freed - reclaim_str_hashtbl in<br /> particularly.<br /> <br /> We cannot hold nfsd_mutex across the nfsd4_end_grace() call as that is<br /> held while client_tracking_op-&gt;init() is called and that can wait for<br /> an upcall to nfsdcltrack which can write to v4_end_grace, resulting in a<br /> deadlock.<br /> <br /> nfsd4_end_grace() is also called by the landromat work queue and this<br /> doesn&amp;#39;t require locking as server shutdown will stop the work and wait<br /> for it before freeing anything that nfsd4_end_grace() might access.<br /> <br /> However, we must be sure that writing to v4_end_grace doesn&amp;#39;t restart<br /> the work item after shutdown has already waited for it. For this we<br /> add a new flag protected with nn-&gt;client_lock. It is set only while it<br /> is safe to make client tracking calls, and v4_end_grace only schedules<br /> work while the flag is set with the spinlock held.<br /> <br /> So this patch adds a nfsd_net field "client_tracking_active" which is<br /> set as described. Another field "grace_end_forced", is set when<br /> v4_end_grace is written. After this is set, and providing<br /> client_tracking_active is set, the laundromat is scheduled.<br /> This "grace_end_forced" field bypasses other checks for whether the<br /> grace period has finished.<br /> <br /> This resolves a race which can result in use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: prevent potential out-of-bounds reads in handle_auth_done()<br /> <br /> Perform an explicit bounds check on payload_len to avoid a possible<br /> out-of-bounds access in the callout.<br /> <br /> [ idryomov: changelog ]

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

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

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

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