Where
AND
AND
AND
-Infinity
0
Severity
7.8
Race Condition
AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

In the Linux kernel, the following vulnerability has been resolved:

posix-cpu-timers: fix race between handleposixcputimers() and posixcputimerdel()

If an exiting non-autoreaping task has already passed exitnotify() and calls handleposixcputimers() from IRQ, it can be reaped by its parent or debugger right after unlocktasksighand().

If a concurrent posixcputimerdel() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cputimertaskrcu() and/or locktasksighand() will fail.

Add the tsk->exitstate check into runposixcputimers() to fix this.

This fix is not needed if CONFIGPOSIXCPUTIMERSTASKWORK=y, because exittaskwork() is called before exitnotify(). But the check still makes sense, taskworkadd(&tsk->posixcputimerswork.work) will fail anyway in this case.

1 / 3
Source: Red Hat
First published (updated )
Severity
7.8
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

crypto: algifaead - Revert to operating out-of-place

1 / 5
Source: Microsoft
First published (updated )
Severity
7.8
Race Condition
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Fragnesia is a universal Linux local privilege escalation exploit, discovered by William Bowling with the V12 team. Fragnesia is a member of the Dirty Frag vulnerability class. This is a separate bug in the ESP/XFRM from dirtyfrag which has received its own patch. However, it is in the same surface and the mitigation is the same as for dirtyfrag.

It abuses a logic bug in the Linux XFRM ESP-in-TCP subsystem to achieve arbitrary byte writes into the kernel page cache of read-only files, without requiring any race condition.

The technique extends the page-cache write bug class that includes Dirty Pipe: when a TCP socket transitions to espintcp ULP mode after data has already been spliced from a file into the receive queue, the kernel processes the queued file pages as ESP ciphertext. The AES-GCM keystream byte at counter block position 2, byte 0 is XORed directly into the cached file page. By selecting the IV nonce to produce a desired keystream byte, any target byte in the file can be set to any value — one byte per trigger invocation.

The exploit builds a 256-entry lookup table mapping each possible keystream byte to its corresponding nonce, then iterates over a payload, firing the splice/ULP race for each byte that needs changing. It writes a small position-independent ELF stub (setresuid/setresgid/execve /bin/sh) over the first 192 bytes of /usr/bin/su in the page cache, then calls execve("/usr/bin/su") to obtain a root shell. The page cache modification is not backed to disk; the on-disk binary is untouched.

1 / 5
Source: Red Hat
First published (updated )
Severity
8.8
AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H/E:P

In the Linux kernel, the following vulnerability has been resolved:

1 / 7
Source: Launchpad
First published (updated )
Severity
7.8
Use After Free
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nftables: fix use-after-free in nftablesaddchain()

nftablesaddchain() publishes the chain to table->chains via listaddtailrcu() (in nftchainadd()) before registering hooks. If nftablesregisterhook() then fails, the error path calls nftchaindel() (listdelrcu()) followed by nftableschaindestroy() with no RCU grace period in between.

This creates two use-after-free conditions:

1) Control-plane: nftablesdumpchains() traverses table->chains under rcureadlock(). A concurrent dump can still be walking the chain when the error path frees it.

2) Packet path: for NFPROTOINET, nfregisternethook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nftdochain() via the transient IPv4 hook can still be dereferencing chain->blobgenX when the error path frees the chain.

Add synchronizercu() between nftchaindel() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.

1 / 4
Source: NVD
First published (updated )
Severity
7.8
3 Months
AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H

In ip6appenddata(), when the paged-allocation branch is taken (MSGMORE / NETIFFSG / large fraglen), alloclen and pagedlen are computed as

alloclen = fragheaderlen + transhdrlen; pagedlen = datalen - transhdrlen;

datalen already includes fraggap (datalen = length + fraggap). When fraggap is non-zero, this is not the first skb and transhdrlen is zero. The fraggap bytes carried over from the previous skb are copied just past the fragment headers in the new skb's linear area. The linear area is therefore undersized by fraggap bytes while pagedlen is overstated by the same amount, and the copy writes past skb->end into the trailing skbsharedinfo.

An unprivileged user can trigger this via a UDPv6 socket using MSGMORE together with MSGSPLICEPAGES.

The bad accounting was introduced by commit 773ba4fe9104 ("ipv6: avoid partial copy for zc"). Before commit ce650a166335 ("udp6: Fix ip6appenddata()'s handling of MSGSPLICEPAGES"), the negative copy value caused -EINVAL to be returned. That later commit allowed MSGSPLICEPAGES to proceed in this case, making the corruption triggerable.

The non-paged branch sets alloclen to fraglen, which already accounts for fraggap because datalen does. Bring the paged branch in line by adding fraggap to alloclen and subtracting it from pagedlen.

After this adjustment, copy no longer collapses to -fraggap on the paged path, so remove the stale comment describing that old arithmetic. Since a negative copy is no longer expected for a valid MSGSPLICEPAGES case, remove the MSGSPLICEPAGES exception from the negative copy check.

1 / 4
Source: Red Hat
First published (updated )
Severity
7.8
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

dm-bufio: don't schedule in atomic context

1 / 2
Source: Microsoft
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203