This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute high-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.5.
This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute high-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.5.
This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 8.8.
This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 8.8.
This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 8.8. The following CVEs are assigned: CVE-2026-98797.
This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 8.8. The following CVEs are assigned: CVE-2026-98797.
This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2026-98130.
This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2026-98130.
This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2026-99284.
This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2026-99284.
This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute high-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.5. The following CVEs are assigned: CVE-2024-50073.
This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute high-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.5. The following CVEs are assigned: CVE-2024-50073.
This vulnerability allows remote attackers to disclose sensitive information on affected installations of Linux Kernel. Authentication is required to exploit this vulnerability. However, only systems with ksmbd enabled are vulnerable. The ZDI has assigned a CVSS rating of 7.1. The following CVEs are assigned: CVE-2026-64138.
This vulnerability allows remote attackers to disclose sensitive information on affected installations of Linux Kernel. Authentication is required to exploit this vulnerability. However, only systems with ksmbd enabled are vulnerable. The ZDI has assigned a CVSS rating of 7.1. The following CVEs are assigned: CVE-2026-64138.
This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute high-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.5.
This vulnerability allows local attackers to escalate privileges on affected installations of Linux Kernel. An attacker must first obtain the ability to execute high-privileged code on the target system in order to exploit this vulnerability. The ZDI has assigned a CVSS rating of 7.5.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Xen Security Advisory CVE-2026-99287 / XSA-532
Linux xen-netback: guest can trigger double unmap of memory
ISSUE DESCRIPTION =================
When xen-netback is setting up the connection to a frontend, it is mapping the ring pages and then validating the ring pages' contents. In case the ring index values are illegal, xen-netback tries to unmap all allocated resources of the connection. Due to a missing test for already unmapped memory, the unmap can happen twice, resulting in a potential unmap of another guest's memory page.
IMPACT ======
The most likely outcome is a driver crash, possibly escalated to a host crash. This then is a Denial of Service (DoS) affecting the entire host.
Information leaks or privilege escalations cannot be ruled out.
VULNERABLE SYSTEMS ==================
Linux versions 5.5 and newer are vulnerable.
MITIGATION ==========
Using a userspace PV network backend (e.g. the qemu based "qnic" backend) will mitigate the problem.
Using a dedicated network driver domain per guest will mitigate the problem.
CREDITS =======
This issue was discovered by Tu Dinh of Vates.
RESOLUTION ==========
Applying the attached patch resolves this issue.
xsa532-linux.patch Linux
$ sha256sum xsa532 4d835bd07ca645ee9b9dadfffd1224bdfaa28d609c6af3666b38df54486bc9f6 xsa532-linux.patch $
NOTE REGARDING LACK OF EMBARGO ==============================
The issue is affecting the same driver as XSA-531, which has no embargo, too. -----BEGIN PGP SIGNATURE-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmrzZgcMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZwDEH/AyWeZ/6Ej8kaE1nqKU740uF2dPKn9zrcazgcNlW gkisqJn+RQm2b3SRoYrnxWMLQOTvWpPQTbKrJmVUk4ehPUr8OJrpyTwihX5iA7zs q995XWsDraOAGL6vw3msrPJBqERB2JFmJG2XcqxlqFpSdhAXpb7nSM2YBm3EhjQp xJnZ6t8dBEaB+lOsP5sD3KtXUIlui7crrwkuwFQmosWkGfbAIHoyvYVLqWedA8yy Dm+9Wtze82oPy9dvn8qLF2Q9xsehkOw3o9A6lROWJk73ExlA0xHLwhuns8Q/86y/ bRKjybJ7wZXX3Rjtzupjs6/68nzGNyN/1aAmwCFOo+eP9UQ= =O99r -----END PGP SIGNATURE-----
In the Linux kernel, the following vulnerability has been resolved:
inet: reject unhashed sockets during established lookups
TCP established ehash lookups are lockless. The socket caches involved use SLABTYPESAFEBYRCU, so memory can be reused before an RCU reader that retained its old address has finished.
After a tuple match, inetlookupestablished() and inet6lookupestablished() acquire a reference and repeat the tuple check. They do not check whether the new object is hashed. If the address is reused for a socket with the same tuple, the lookup can acquire a reference to the new object and return it while its nulls node is unhashed.
A PoC that drives reuse with a SYN cookie request socket reproduced the crash. The new request socket is unhashed and has a NULL rsklistener. A lookup that had loaded the address of the old request socket acquired the reference published by tcpgetcookiesock() and returned the new object. tcpv4rcv() then read skstate through the NULL listener.
The resulting crash was:
BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page ... Oops: Oops: 0000 [#1] SMP NOPTI CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 7.3.0-00591-g0e135910deec #1 PREEMPT(lazy) ... RIP: 0010:tcpv4rcv+0x44e/0x1280 ... R10: 0000000000000001 R11: 00000000024ca8c0 R12: 0000000000000000 ... CR2: 0000000000000012 CR3: 0000000103d50004 CR4: 0000000000770ef0 ... Call Trace: <IRQ> ? rawlocaldeliver+0xae/0x240 ipprotocoldeliverrcu+0x2d/0x180 iplocaldeliverfinish+0x84/0x100 ipsublistrcvfinish+0x5f/0x70 ipsublistrcv+0x12a/0x1d0 iplistrcv+0xfd/0x130 netifreceiveskblistcore+0x223/0x250 netifreceiveskblistinternal+0x1d2/0x2c0 ? tryfillrecv+0x39/0x7b0 napicompletedone+0x74/0x170 virtnetpoll+0x445/0x600 napipoll+0x27/0x1e0 netrxaction+0x2fe/0x3b0 handlesoftirqs+0xc2/0x2c0 irqexitrcu+0x74/0xd0 commoninterrupt+0x7f/0x90 </IRQ> ... Kernel panic - not syncing: Fatal exception in interrupt
After taking a reference, check whether the nulls node is unhashed in both IPv4 and IPv6 established lookups. If it is unhashed or the tuple no longer matches, drop the reference and restart the lookup.
Lookups racing with the TIMEWAIT hashdance, or with a request being replaced by its child, now restart and find the new socket instead of returning the old one.
Request sockets that were never inserted into ehash can have a nonzero refcount, and a stale lookup can hold a transient reference. Therefore, when SYN cookie, Fast Open, and request migration paths fail after setting a nonzero refcount, release the references held by those paths with reqskput() instead of freeing the request directly.
In the Linux kernel, the following vulnerability has been resolved:
xen-netback: Zero out sring pointers on unmap
If xenvifmapfrontenddatarings() fails when a ring is already mapped, it unmaps them via xenvifunmapfrontenddatarings() which keeps the ring pointers unchanged. xenvifconnectdata()'s cleanup path calls xenvifdisconnectqueue() which in turn calls xenvifunmapfrontenddatarings() again, which will attempt to unmap the pointers a second time.
Zero out the ring pointers after they are unmapped to avoid this issue.
This is XSA-532
In the Linux kernel, the following vulnerability has been resolved:
xen-netback: Fix XenBus connection failure cleanup
xenvifgetstats and xenvifgetethtoolstats capture vif->numqueues under rcureadlock. We need to unpublish vif->numqueues before synchronizenet to ensure that readers that come afterwards will not read a non-zero vif->numqueues and attempt to access invalid queues.
This is the same cleanup algorithm as used in backenddisconnect and added in commit b17075d5c198 ("xen-netback: fix race condition on XenBus disconnect").
This is XSA-531
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftbyteorder: remove multi-register support
64bit byteorder conversion is broken when several registers need to be converted because the source register array advances in steps for 4 bytes instead of 8:
for (i = ... src64 = nftregload64(&src[i]); ~~~~~ u32 src nftregstore64(&dst64[i],
Remove the multi-register support, it has other issues as well:
Pablo points out that commit caf3ef7468f7 ("netfilter: nftables: prevent OOB access in nftbyteordereval") alters semantics: before the loop operated on registers, i.e. for ( ... ) dst32[i] = htons((u16)src32[i])
.. but after the patch it will operate on bytes, which makes this useless to convert e.g. concatenations, which store each compound in its own register.
Multi-convert of u32 has one theoretical application:
ct mark . meta mark . tcp dport @intervalset
Because ct mark and meta mark are host byte order, use with intervals has to convert the byteorder for ct/meta mark value to network byte order (bigendian).
nftables emits this: [ meta load mark => reg 1 ] [ byteorder reg 1 = hton(reg 1, 4, 4) ] [ ct load mark => reg 9 ] [ byteorder reg 9 = hton(reg 9, 4, 4) ] ...
I.e. two separate calls. Theoretically it could be changed to do: [ meta load mark => reg 1 ] [ ct load mark => reg 9 ] [ byteorder reg 1 = htonl(reg 1, 4, 8) ] ...
But then all it would take to change the set to meta mark . tcp dport . ct mark
... and we'd be back to two "byteorder" calls. IOW, support to convert a range of registers is both dysfunctional and dubious.
Simplify this: remove the feature.
Pablo Neira Ayuso points out that nftables before 1.1.0 can generate incorrect byteorder conversions, see 9fe58952c45a, "evaluate: skip byteorder conversion for selector smaller than 2 bytes" in nftables.git). Affected rulesets fail to load with this change and old userspace due to 'len != size' check.
IBM Aspera Faspex 5.0.0 through 5.0.19 could allow an authorized user to craft a specific message to bypass user authorization and gain full administrative privileges.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Xen Security Advisory CVE-2026-100082 / XSA-528
Linux xen-blkback: guest can trigger use-after-free for reading statistic data
ISSUE DESCRIPTION =================
he driver does not serialise reads of the device I/O statistics against the freeing of the memory that holds them. This leads to a use-after-free when reading statistical counters while the device is being torn down.
IMPACT ======
This most likely crashes the driver, and possibly the host, causing a Denial of Service (DoS) for the entire host.
Information leaks cannot be ruled out.
VULNERABLE SYSTEMS ==================
Linux versions 4.5 and newer are vulnerable.
MITIGATION ==========
Using a userspace PV block backend (e.g. the qemu based "qdisk" backend) will mitigate the problem.
Using a dedicated block driver domain per guest will mitigate the problem.
CREDITS =======
This issue was discovered by Yehyeong Lee of Hyundai Mobis.
RESOLUTION ==========
Applying the attached patch resolves this issue.
xsa528-linux.patch Linux
$ sha256sum xsa528 848d5cc56a7b31e84399ac00d616c36bd2b5efdcc0f23017a7590b1b58900c19 xsa528-linux.patch $
NOTE REGARDING LACK OF EMBARGO ==============================
A very similar issue was disclosed in public. -----BEGIN PGP SIGNATURE-----
iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmrt7tAMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZTFkH/jRhPRPUnQb/2KV42fKAPvQtffdEIWr72wc5ogYm d6rTBU81hLdZAyq+Zo2jwhgggjXNeurD84z1Lnr8X6YgnRBAHfWhOd28V583K83j BzmWsbFeUsMLjiaWuftzdr1RdpqB1ajk6NRAnR5Eb4jrWltIOekDgSviJupMfbRs iq9pM0J/zbFBcIu21Lor4R5F8wYLx3cbzE0LuSq0j+D5uCMFIAhkea+7ReadQYxr +L3LbEJIdcGpfZlcf9SRgJ8KKJr6d3JlHAVx2fpq8w/buwRFv3M87VL64MPUk7Tr kJ/Wpl+hpvnTNE0m88eF1x3pMkdco6fwzz/xg7lvxm1k2Ho= =CcMW -----END PGP SIGNATURE-----
Insufficient validation of length fields in the GNSS firmware loader can result in kernel‑memory corruption.
On Sat, Oct 31, 2026 at 04:01:47PM +0000, Rui Sousa wrote: Hello,
An additional hardening option for CVE-2026-98432 (the IPv4 TCP inetopt use-after-free), for systems that cannot take a fixed kernel yet.
The interim mitigations published so far (for example AlmaLinux's, at <https://almalinux.org/blog/2026-10-30-cve-2026-98432/>) are an nftables rule dropping inbound TCP that carries IPv4 options and disabling MPTCP. They do not mention the initonfree=1 kernel boot parameter.
initonfree=1 (mainline since 5.3) zeroes slab objects and pages when they are freed. It does not fix this bug: the stale pointer is still dereferenced. But a use-after-free read of the freed object then returns zeroes instead of its previous contents, which narrows what an attacker can learn through it. Hi Rui,
I'm a member of the kernel team at CIQ.
I looked into your initonfree=1 suggestion, and unfortunately it doesn't do anything meaningful against this CVE. The remote KASLR defeat uses pointers leaked from live slab objects via an out-of-bounds read on the freed object. The previous contents of the freed object aren't useful.
I had Claude Mythos analyze the code and Anthropic's exploit description [1], and this is what it found:
The freed object is a struct ipoptionsrcu: a 32-byte header that holds the u8 optlen, followed by the option bytes to echo. The allocation is sized from the SYN's option length of at most 40 bytes, putting the object in kmalloc-64 or kmalloc-96. As long as the slot hasn't been reused, the stored length is still the one the kernel wrote, which never exceeds the space allocated for the option bytes. The SYN-ACK then echoes options built from the attacker's own SYN, plus at most an obfuscated freelist pointer, and the copy never reaches past the object. With initonfree=1, the stored length is zero instead and the SYN-ACK simply carries no options.
Anthropic describes stage one as making the kernel "read an attacker-controlled length field to copy extra bytes and send them back to the attacker". The kernel never stores a length larger than the space it allocated, so an attacker-controlled length can only come from another allocation that has reused the slot and placed its own data where optlen lives. The overread then starts in that live object and runs into its neighbors, and initonfree=1 never touches live memory. Zeroing on free only affects free slots, and an overread that returns no pointer costs the attacker nothing but another attempt. The attacker keeps trying until the overread lands on a live neighbor that holds a kernel pointer. Stage two depends on the same reused slot and is unaffected for the same reason. Anthropic didn't name the reusing allocation. The reuse is inferred from the code, not from their write-up.
So initonfree=1 is harmless, but it isn't a mitigation for this CVE and shouldn't carry weight in advisories. Dropping inbound TCP with IP options stops the object from being allocated at all, though traffic between containers on the same host can bypass that filter. Disabling MPTCP alone isn't enough, since the bug is in plain IPv4 TCP.
[1] https://www.anthropic.com/research/discovering-vulnerabilities-with-claude
Sultan
See: https://access.redhat.com/security/vulnerabilities/RHSB-2026-016
The mitigation until the kernel patch is released is to drop using this NFTables rule:
table inet cve202698432 { chain input { type filter hook input priority -310; policy accept; ip protocol tcp ip hdrlength > 5 counter drop } }
I'm trying to trigger the rule counter or at least see the packet in TCPdump using Python Scapy. So far I was only able to see the packet on my home LAN.
from scapy.all import IP, TCP, send
pkt = IP( dst="SOMEIP", options=[b'\x01\x01\x01\x01'] ) / TCP( dport=SOMEPORT, flags="S" )
send(pkt)
Has anyone confirmed this works? I have no idea why I can't get it to show on my servers.
I'm tired, boss.
Linux kernel vulnerable to remote root compromise by listening for a TCP connection CVSS ranges from 8 ish to 9.8 Some distributions have fixes released, others are dragging their feet The bug is in how the Linux kernel handles options in the TCP packet header Dropping packets with any TCP options set blocks the attack (and may be a good idea generally) Title of this post is not strictly accurate but cannot be edited Multipath TCP listeners significantly increase the likelihood of a successful attack Programs have to enable the MCTCP socket option to get MCTCP Recent versions of the Go programming language/system enable MCTCP by default Use ss -M -l to see if you have any MCTCP listeners at the moment Set the kernel option net.mptcp.enabled to 0 to block MCTCP listeners Disabling MCTCP does not solve the bug, it just makes exploitation harder More info https://thehackernews.com/2026/10/linux-kernel-tcp-flaw-with-98-cvss.html