Operating system, libraries and runtimes

Linux kernel: ebtables SNAT (CVE-2026-53266) and the local root quartet

Linux kernel ebtables SNAT check

CVE-2026-53266 is an out-of-bounds write in the bridge netfilter ebtables SNAT target. CISA added it to its Known Exploited Vulnerabilities catalog on 18 September 2026 with a three-day federal deadline, and Red Hat confirmed exploitation.

How the flaw works

When an ebtables SNAT rule uses the ARP rewrite option (--snat-arp), the target writes the new hardware address into the ARP header of the packet with skb_store_bits(). The option exists in both the legacy ebtables and the nft-based ebtables-nft tool, which describes it as "also change src address in arp msg". The vulnerable code did not first make that range of the socket buffer writable, so the write could land in a fragment backed by memory the kernel did not own at that moment, for example a page imported from a file by splice. The fix calls skb_ensure_writable() on the range before the write.

Why the script reads the kernel's origin first

The upstream patch level is visible in the release string only on kernels that follow the stable series (vanilla builds, Arch, Alpine, most custom kernels). Debian carries it in uname -v. Ubuntu, RHEL and its derivatives, SUSE and Amazon Linux backport fixes under release strings that do not say which fixes they contain (for example 6.8.0-45-generic or 5.14.0-503.el9), so a number taken from them cannot be compared with the table above. A script that did would mark nearly every distribution kernel as vulnerable.

A stable release candidate (7.0.13-rc1) comes before the release it leads to and may not carry the fix, so it is judged as the release before it (7.0.12). A mainline candidate of a newer series (7.1.0-rc3) is judged by its series.

Quick start

curl -fLO https://raw.githubusercontent.com/PrivacySafe/security-patches/refs/heads/main/linux-kernel/linux-kernel-check.sh
less linux-kernel-check.sh
chmod +x linux-kernel-check.sh
./linux-kernel-check.sh check

Commands

Env: KERNEL_CHANGELOG (a vendor changelog to read, plain or .gz), and KERNEL_RELEASE, KERNEL_VERSION_STRING, KERNEL_MODULES_FILE and KERNEL_PROC_SYS to override uname -r, uname -v, /proc/modules and /proc/sys.

Commands that change the host need root. Run them with sudo from an admin account, not from a root login, so the change is recorded against a person. The script stops and prints the exact command if you forget:

sudo ./linux-kernel-lpe-check.sh mitigate --userns --dry-run
sudo ./linux-kernel-lpe-check.sh mitigate --userns
sudo ./linux-kernel-lpe-check.sh rollback

Exposure information

The script also reports ebtables SNAT rules (and whether any uses --snat-arp), whether the ebt_snat module is loaded or loadable, and whether unprivileged user namespaces are allowed. Read these carefully: seeing no such rule on the host does not make a kernel safe. A local user with CAP_NET_ADMIN inside a user namespace may be able to create a rule in their own network namespace. That reading is the project's, so the lines are information and do not change the exit code.

Update

Install your vendor's fixed kernel and reboot. Upstream fixes are 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.94, 6.18.36 and 7.0.13.

Until you can, PrivacySafe suggests the following. Remove ebtables SNAT rules that use --snat-arp. Where ebt_snat is not needed, prevent the module from loading. Where unprivileged user namespaces are not needed, disable them. Each of these may affect other software, so apply them with care.

Sources

• CISA alert, 18 September 2026
• The Hacker News: three Linux kernel flaws exploited
• Fixed versions and mitigation summary
• net/bridge/netfilter/ebt_snat.c in the Linux kernel
• extensions/libebt_snat.c in iptables (the --snat-arp option)

Linux kernel IPv4 TCP use-after-free (CVE-2026-98432)

Script: linux-kernel/linux-kernel-ireq-opt-check.sh

A race in the Linux kernel's IPv4 TCP handshake, published as CVE-2026-98432 on 15 October 2026 and discussed on oss-security from 30 October to 3 November. tcp_v4_syn_recv_sock() hands the request socket's IP options to the child socket without copying them. A retransmitted SYN for the same request socket, handled on another CPU, can still be building a SYNACK from those options when the child socket is destroyed, and inet_sock_destruct() and tcp_v4_reqsk_destructor() free them with a plain kfree() instead of kfree_rcu(): a use after free in ip_options_build(). Request socket migration (net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program) reaches the same bug.

The attacker is an unauthenticated peer who sends a SYN that carries IPv4 options, such as Record Route or Timestamp, to any listening TCP port. No account and no user interaction are needed, and a firewall that allows the port does not help. The CVE record scores it 9.8 (Critical). Red Hat first scored it 5.9 (Moderate) and now rates it Critical. AWS's bulletin 2026-160-AWS says researchers have demonstrated unauthenticated remote code execution against a host with a Multipath TCP (MPTCP) listener, that a kernel crash or a disclosure of kernel memory are the other outcomes, and that it had no evidence of exploitation when it last updated the bulletin on 2 November. IPv6 is not affected by this flaw, and kernels before 4.4 are not affected.

Fixed versions

The first stable release of each branch that carries the fix. A branch not in the table (4.4 to 5.9, 5.11 to 5.14, 5.16 to 6.0, 6.2 to 6.5, 6.7 to 6.11, 6.13 to 6.17, 6.19 to 7.1, and older ones such as 4.14, 4.19 and 5.4) is affected and has no upstream fix. The fix there is a vendor kernel or a move to a listed branch.

Vendors that backport, as published on 3 November. These states change daily, so open your vendor's page before you act on this list.

Canonical's position is that security updates are the only appropriate mitigation and that switching MPTCP off is not enough on its own. Red Hat says the same of its filter below: it reduces exposure and cannot fully prevent it.

How the script judges the kernel

It reads the kernel's origin first, exactly as the other kernel checks above do. A kernel that follows the stable series (vanilla, Arch, Alpine, most custom builds) is judged on the upstream version in uname -r. Debian's upstream version is read from uname -v. A stable release candidate such as 6.12.113-rc1 is judged as the release before it. Ubuntu, RHEL and its derivatives, SUSE and Amazon Linux backport fixes under release strings that do not say which fixes they carry, so for them the vendor changelog is the evidence: the script looks in it for CVE-2026-98432, and when it is absent it says so and points you to your vendor's tracker instead of guessing.

Quick start

curl -fLO https://raw.githubusercontent.com/PrivacySafe/security-patches/refs/heads/main/linux-kernel/linux-kernel-ireq-opt-check.sh
less linux-kernel-ireq-opt-check.sh
chmod +x linux-kernel-ireq-opt-check.sh
./linux-kernel-ireq-opt-check.sh check

Env: KERNEL_CHANGELOG (a vendor changelog file to read, plain or .gz), KERNEL_RELEASE and KERNEL_VERSION_STRING (override uname -r and uname -v), KERNEL_MODULES_FILE, KERNEL_PROC_SYS and KERNEL_BUILTIN_FILE (override /proc/modules, /proc/sys and the module list of the release), KERNEL_LOG_FILES (the log files hunt reads, instead of the defaults), KERNEL_INSTALLED_RELEASES (the installed kernel releases, instead of /lib/modules), OS_RELEASE_FILE, and STATE_DIR, SYSCTL_D and MODPROBE_D for mitigate and rollback.

A container shows the host's kernel, so run the script on the host.

Exposure information

While the kernel is affected, check reports whether MPTCP is on (net.mptcp.enabled) and whether the mptcp module is built in, loaded or loadable, how many MPTCP sockets and how many IPv4 TCP listeners that are not on loopback exist, whether net.ipv4.tcp_migrate_req is set, and whether a filter that drops TCP packets with IP options is in place. That is information for you to weigh, not a verdict: a kernel below its fixed release is affected whatever these show. Go programs built with Go 1.24 or later listen with MPTCP by default when the kernel allows it, and GODEBUG=multipathtcp=0 turns that off for one program (under systemd, Environment=GODEBUG=multipathtcp=0 in a drop-in; merge it into any GODEBUG the unit already sets). A godebug multipathtcp=0 line in the go.mod of a program you build does the same, and a program whose go.mod declares an older Go keeps MPTCP off. A program that asks for MPTCP in code is not changed by the variable. The kernel default decides the rest: the RHEL family builds ship net.mptcp.enabled=0 (AlmaLinux says so, and Rocky 9 and 10 report it), Debian and Ubuntu kernels ship 1, so a Go service is an MPTCP listener on Debian and Ubuntu and plain TCP on a stock Rocky host.

Finding MPTCP listeners

ss -M -l -n -p lists them, and ss -tlnp cannot tell an MPTCP listener from a TCP one. ss -M reads the mptcp_diag module. Where it is not loaded, ss -M prints an empty table even with an MPTCP listener running, with no error; Ubuntu cloud and virtual kernels keep the module in linux-modules-extra-$(uname -r), so run sudo apt install linux-modules-extra-$(uname -r) and sudo modprobe mptcp_diag. check therefore also reads the socket count the kernel keeps in /proc/net/protocols (the MPTCP and MPTCPv6 rows, which count listening and other sockets) and says so when ss -M lists none while that count is above zero. A script that audits a fleet should use both. Do not block mptcp_diag to reduce exposure: the flawed code is in IPv4 TCP, and the block only hides MPTCP sockets from ss -M.

net.mptcp.enabled, ss and /proc/net/protocols all describe one network namespace. A new namespace starts at 1 whatever the host is set to, so a container with its own namespace is not covered by the host's sysctl and is not shown by the host's ss. Look from inside it, or from the host with sudo nsenter -t "$(docker inspect -f '{{.State.Pid}}' NAME)" -n ss -M -l -n -p, and turn MPTCP off for it when it starts (docker run --sysctl net.mptcp.enabled=0). A container started with --network=host shares the host's namespace. In Kubernetes, net.mptcp.enabled is not in the safe sysctl set, so a pod that sets it in securityContext.sysctls is scheduled but fails to start on a node whose kubelet has not allowed it (--allowed-unsafe-sysctls, or allowedUnsafeSysctls in the kubelet configuration). A kubelet can also set it for every pod on the node with defaultPodSysctls, which needs no allow-list. net.* sysctls cannot be set on a pod that uses host networking.

Mitigation: mitigate

./linux-kernel-ireq-opt-check.sh mitigate --dry-run shows, and mitigate applies, measures that reduce the exposure. They are not a fix. mitigate acts only when check finds the kernel affected (--force overrides) and you must choose what to apply, because each measure can break software:

rollback restores the saved sysctl values and removes the files and the packet filter. A patched kernel and a reboot are the only complete remedy. The kernel module blocker does the module part for any module, with a list and a status command.

Hunt

The flaw leaves a trace when it goes wrong: a use after free or a skb_under_panic in the kernel log. hunt looks for it. A hit means the kernel faulted in this code, not that someone attacked it, so read the full trace and what connected just before it. A clean result is not clearance: a successful exploit need not crash the host, and a reboot clears the ring buffer. Run it with sudo, because the kernel logs belong to root.

Update

Move to your vendor's kernel that names this CVE, or to a stable release from the table, and reboot. The script prints the command for the system it runs on and the vendor's page for the CVE. Debian, Ubuntu, Trisquel and their derivatives are the project's default targets; the RPM family is covered as well; SUSE, Arch and Alpine get the command and the vendor page.

check also says when a fixed kernel is already installed but not running (the common state after an update without a reboot), and when the package manager already has the fix: the cached apt list --upgradable or dnf updateinfo data is read, never the network.

On an RPM family system: the .rpm release package installs the script under /opt/psf-security-patches; mitigate --ip-options uses nft, which RHEL 8 and later ship, because the iptables command there is the nftables front end and has no u32 match (the script says so and does not try it); and a running firewalld keeps its own tables, so the one this adds sits beside them.

mitigate --mptcp sets net.mptcp.enabled=0: the kernel then refuses to create new MPTCP sockets (ENOPROTOOPT). It does not close an MPTCP listener that already exists: that one keeps listening until its service restarts. check and mitigate --mptcp count the listeners with ss -M -l and say so, and ss -M -l -p shows which services own them.

If you cannot update yet: switch MPTCP off (mitigate --mptcp), drop TCP packets that carry IP options at the edge or on the host (mitigate --ip-options; AWS Network Firewall users can use the stateful rule in AWS's bulletin), and keep database and other service ports off the internet. On AWS, the bulletin lists what each service needs from you.

Sources

• NVD: CVE-2026-98432
• AWS security bulletin 2026-160-AWS
• OpenCVE: CVE-2026-98432
• oss-security: 30 October, 30 October (second), 31 October and 3 November
• The kernel CVE record
• Debian: DSA-6568-1, DLA-4841-1, DLA-4850-1

Linux kernel module blocker

Script: linux-kernel/linux-kernel-module-block.sh

Many kernel flaws sit in a module that almost nobody needs and that loads by itself the moment an unprivileged process opens the right socket, or a device appears. Stopping that module from loading removes the attack surface until a patched kernel is running. This script does it the way the kernel documents, for a curated list of modules behind recent flaws or for any name you give it, with a manifest and a rollback, and it tells you when a block cannot work. It is generic: the tools above carry their own copies of this logic for their own modules and keep working when copied on their own.

A block is a file of its own, /etc/modprobe.d/psf-block-NAME.conf, with blacklist NAME, which stops the alias based autoload, and install NAME /bin/false, which also stops an explicit modprobe NAME. A hyphen and an underscore are the same thing to the kernel, and the script treats them so.

A bare blacklist line, which is what many distributions ship (Ubuntu's own /etc/modprobe.d/blacklist-*.conf files, for one), stops only the automatic load by alias. An explicit modprobe NAME still loads the module, and so does another module that depends on it. list and check call that blacklist, not blocked, and block adds the install rule on top. Rules that already exist anywhere under modprobe.d count, wherever they came from.

Quick start

curl -fLO https://raw.githubusercontent.com/PrivacySafe/security-patches/refs/heads/main/linux-kernel/linux-kernel-module-block.sh
less linux-kernel-module-block.sh
chmod +x linux-kernel-module-block.sh
./linux-kernel-module-block.sh list --present        # what this host has from the list
./linux-kernel-module-block.sh check tun             # what it is, what holds it, how it loads
sudo ./linux-kernel-module-block.sh block sctp --dry-run
sudo ./linux-kernel-module-block.sh block sctp
./linux-kernel-module-block.sh status

Env: STATE_DIR and MODPROBE_D (where the manifest and the block files go), MODPROBE_DIRS (the other directories searched for rules that already exist), KERNEL_RELEASE, KERNEL_MODULES_FILE, KERNEL_BUILTIN_FILE (override uname -r, /proc/modules and the module list of the release), SYS_MODULE_DIR and OS_RELEASE_FILE.

Commands that change the host need root. Run them with sudo from an admin account, not from a root login, so the change is recorded against a person. The script stops and prints the exact command if you forget.

Only one run changes the host at a time: a second block or rollback waits for the first (PSF_LOCK_WAIT seconds, default 30, lock file STATE_DIR/.lock) and then stops with exit 2 and says why. Without that, runs started together can overwrite each other's manifest entries and leave blocks that a rollback no longer knows about. The manifest itself is replaced whole through a temporary file, so an interrupted run leaves the old one or the new one. mitigate and rollback in the two tools above take the same lock.

The list

Three groups, each labeled for what it is. list shows all 42 rows with the CVE, what a block breaks and the state on your host.

A module marked * is one that detection depends on. mptcp_diag is the module ss -M reads to list MPTCP sockets, and this collection's own checks use it. The flawed code of CVE-2026-98432 is in IPv4 TCP, not in mptcp_diag, so blocking it removes no known exposure and hides the MPTCP listeners you would look for. block --group and block --cve therefore skip it and say so, and it is blocked only when you name it and add --force. A row you add with --list-file can carry the same flag as a seventh field, keep.

The list is a table in the script and is updated with each release; --list-file FILE adds your own rows (module|group|CVEs|what needs it|what a block breaks|switch for a built-in module, with the group custom allowed). The scripts do not fetch anything.

What a block cannot do

The rebuild command by system: update-initramfs -u -k all on Debian, Ubuntu, Trisquel and derivatives, which copies everything in /etc/modprobe.d into the image; dracut -f --regenerate-all -I "/etc/modprobe.d/psf-block-*.conf" on RHEL, Alma, Rocky, Fedora, Amazon Linux and SUSE, where -I is needed because dracut reads /etc/modprobe.d only for a host-only image (the usual kind for the running system, but not the generic one) and does not mind when nothing matches, as after a rollback; mkinitcpio -P on Arch; mkinitfs on Alpine. The same applies after a rollback. A new kernel's image is built by your distribution's own hook: a host-only image carries the files, a generic one does not unless dracut is told to include them. A kernel command line option, module_blacklist=NAME, is the alternative for a module you cannot get a file in place for; the script does not touch the boot loader.

Why a block helps

check shows how a module loads. Network protocol modules have net-pf- aliases: any process, with no privileges, loads one by opening a socket of that family. That is why a block removes a real path for an attacker. Filesystem modules load when something mounts that type, USB modules when a matching device is plugged in.

Before you run it

• These are checks, not fixes, and the fix needs a reboot. The checks judge the running kernel. Update to your vendor's fixed kernel and reboot. A container shows the host's kernel, so run them on the host.
• A vendor kernel's number does not show its fixes. Ubuntu, RHEL and its derivatives, SUSE and Amazon Linux backport fixes under release strings that do not say which they carry. For those the script reads the vendor changelog for each CVE and points you to the vendor's tracker when a CVE is absent.
• The quartet is judged flaw by flaw. Each of the four has its own fixed release per branch, so 6.12.105 can have two of the four fixes and not the other two. Branches with no upstream fix (for example 5.4) need a vendor kernel.
• Exposure lines are information, not a verdict. A kernel below its fixed release is affected whatever the module and user-namespace lines show. No ebtables rule does not make the ebtables kernel safe, since a local user with CAP_NET_ADMIN in a user namespace may be able to create one.
• The protective measures are PrivacySafe's. The ebtables suggestions are the project's, and the quartet's (disable unprivileged user namespaces, disable unused AH6, TUN, PPPoE and SCTP) are the researcher's from the disclosure. DiagSpill is not stopped by the namespace setting. There is no hunt for either.

Linux kernel local root quartet check

Script: linux-kernel/linux-kernel-lpe-check.sh

Four local privilege escalation flaws in the Linux kernel were disclosed on the oss-security list on 18 September 2026, after an embargo agreed with the linux-distros list (they were reported to the kernel security team in mid-July). Public proof-of-concept exploits exist for all four. Each takes an unprivileged local user to root on the systems it targets, each can corrupt the host kernel from a container, and the bugs are 10 to 21 years old.

Two of them can be turned into a remote crash under narrow conditions: DirtyAH6 if the host routes IPv6 and adds an Authentication Header in transport mode, and DiagSpill only with non-default SCTP options (ASCONF with SCTP-AUTH, or net.sctp.addip_noauth_enable=1). The researcher showed remote root for DirtyAH6 only in a lab with on-target memory grooming, and sees no path to remote root for DiagSpill.

CVSS scores were not in the sources used for this document, so none is given here. The CVE numbers follow the researcher's own disclosure. A few news write-ups swap the numbers of TUNderflow and PPPoEject.

Fixed versions

The first stable release of each branch that carries each fix. A branch not in the table (5.11 to 5.14, 5.16 to 6.0, 6.2 to 6.5, 6.7 to 6.11, 6.13 to 6.17, 6.19 to 7.0, and older ones such as 5.4) is affected. The fix there is a vendor kernel or a move to a listed branch.

The first stable releases with all four fixes are 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 and 7.2.4. Releases of 7.3 and later carry every fix. The table is why a single "newer than X" rule is wrong here: on 6.12, release 6.12.105 has the PPPoEject and DiagSpill fixes but still lacks the other two.

How the script judges the kernel

It reads the kernel's origin first, exactly as the ebtables check above does. A kernel that follows the stable series (vanilla, Arch, Alpine, most custom builds) is judged on the upstream version in uname -r. Debian's upstream version is read from uname -v. A stable release candidate such as 6.12.109-rc1 is judged as the release before it. Ubuntu, RHEL and its derivatives, SUSE and Amazon Linux backport fixes under release strings that do not show which fixes they carry, so a number from them cannot be compared with the table. For those the script looks in the vendor changelog for each CVE, and points you to the vendor's tracker when a CVE is absent. A kernel that is below a fixed release but whose changelog names the CVE is reported as carrying a backport.

Each of the four is judged separately, and the verdict names the ones still open.

Quick start

curl -fLO https://raw.githubusercontent.com/PrivacySafe/security-patches/refs/heads/main/linux-kernel/linux-kernel-lpe-check.sh
less linux-kernel-lpe-check.sh
chmod +x linux-kernel-lpe-check.sh
./linux-kernel-lpe-check.sh check

Env: KERNEL_CHANGELOG (a vendor changelog file to read, plain or .gz), KERNEL_RELEASE and KERNEL_VERSION_STRING (override uname -r and uname -v), KERNEL_MODULES_FILE, KERNEL_PROC_SYS and KERNEL_BUILTIN_FILE (override /proc/modules, /proc/sys and the module list of the release).

A container shows the host's kernel, so run the script on the host.

Exposure information

For the flaws still open, the script reports whether the module each one needs is loaded, built in or loadable, and whether unprivileged user namespaces are allowed (user.max_user_namespaces, kernel.unprivileged_userns_clone and kernel.apparmor_restrict_unprivileged_userns are read). That is information for you to weigh, not a verdict: a kernel below its fixed release is affected whatever these show, and a process with the right capabilities, such as a container, does not need a user namespace for the first three. That reading is the project's. AppArmor and SELinux did not block the exploits in the researcher's testing, except for Ubuntu's block on unprivileged user namespaces themselves.

Mitigation: mitigate

./linux-kernel-lpe-check.sh mitigate --dry-run shows, and mitigate applies, the researcher's protective measures. It acts only when check finds the kernel affected (--force overrides) and you must choose what to apply, because each measure can break software:

rollback restores the saved sysctl values and removes the files. STATE_DIR, SYSCTL_D and MODPROBE_D can be overridden. To block modules that are not listed here, or several at once, see the kernel module blocker. These are the researcher's measures, applied by PrivacySafe. A patched kernel and a reboot are the permanent fix. The script has been run against simulated /proc/sys and module files and in dry-run mode on a kernel.

There is no hunt

Proof-of-concept code is public for all four, and no indicators of exploitation were published, so the script has no hunt.

Update

Move to your vendor's kernel that names these CVEs, or to a stable release from the table, and reboot. Until then, the researcher suggests in the disclosure (PrivacySafe applies this): disable unprivileged user namespaces, which removes the ordinary-user path to the first three but can break rootless containers and some sandboxes, and disable AH6, TUN, PPPoE and SCTP with sctp_diag where they are not used. A process with the right capabilities, and DiagSpill, are not stopped by the namespace setting.

Sources

• oss-security: A quartet of Linux local root vulns (18 September 2026)
• The researcher's write-up
• The Hacker News: public exploits released for the four kernel flaws
• Proof-of-concept repositories: DirtyAH6, TUNderflow, PPPoEject, DiagSpill

Red Hat advisories

Red Hat's advisory list (security advisories released 2026-04-01 to 2026-11-03) names the CVEs below. A Red Hat build is judged by its RPM release, not by the upstream version number, because Red Hat backports fixes: the advisory names the release that fixes it. A CVE with no advisory in the list has none for that period, which is not the same as not affected. The current state is on Red Hat's CVE database.

The columns are CVE-2026-NNNNN. The table shows, for each stream, the advisories that name each CVE (the number is the part of RHSA-2026:NNNNN after the colon; rt is kernel-rt, kp is a kpatch-patch live patch). A blank cell means no advisory in the list, not that the stream is unaffected. Each advisory is at https://access.redhat.com/errata/RHSA-2026:NNNNN.

The fixed kernels for CVE-2026-98432 (IPv4 TCP use-after-free), newest first. A kernel is fixed if its release is this one or a later one in the same stream:

The Security Patches software and this documentation are dedicated to the public domain under CC0 1.0 Universal. Other pages on privacysafe.app/docs are CC BY-SA 4.0 unless the page says otherwise.

Edit this page on Codeberg