cve-2026-98432 (linux behind opnsense fw)

[paepcke]

https://atlasum.net/blog/cve-2026-98432-linux-ipv4-tcp-uaf

- does not impact FreeBSD
- does impact every Linux behind your (OPNSense-) Firewall that accepts TCP packets

Is there away to identify and drop all impacted packets? With nft i can do ...

nft add table ip cve_2026_98432
nft add chain ip cve_2026_98432 pre '{ type filter hook prerouting priority -300; }'
nft add rule ip cve_2026_98432 pre meta l4proto tcp ip hdrlength gt 5 counter drop


From my understanding:
- pf scrub does not care for tcp (options)
- pf is not able to identify tcp options
- ipfw can (but only well known specific, but can not scrub unknown? maybe by tcp header lenght?)
- firewall chaining is not recommended
- firewall chaining is not part of opnsense (but can be done via script manually)

Any other options/ ideas ? (other than chain/migrate to nft based firewall or dump the complete traffic through ids / suricate screen? )

[Monviech (Cedrik)]

PF has an allow-opts filter-rule modifier. By default, PF blocks packets containing IPv4 options. A pass rule needs allow-opts to permit them.

If you check your ruleset in /tmp/rules.debug you can grep if your ruleset contains rules with allow-opts.

Also if its on a non quick automatic rule that would allow-opts, you can create a quick rule in the same direction that blocks options.

https://docs.opnsense.org/manual/firewall.html#settings

Check the filter tab, its available (advanced setting)

[pfry]

Huh! I'd assumed they were looking at the TCP header Data Offset field (possible using netfilter) - I didn't look closely at the CVE. Makes it easy to filter (as I've always done by default).

For folks like me who sit in the GUI and are too lazy to grep, "Firewall: Diagnostics: Statistics": -> "rules", expand the rulesets, CTRL-f "opts". Should be one: "let out anything from firewall host itself".

[nero355]

PF has an allow-opts filter-rule modifier. By default, PF blocks packets containing IPv4 options. A pass rule needs allow-opts to permit them.

If you check your ruleset in /tmp/rules.debug you can grep if your ruleset contains rules with allow-opts.

Also if its on a non quick automatic rule that would allow-opts, you can create a quick rule in the same direction that blocks options.

So as long as you haven't created any Manual Firewall Rules that Allow TCP traffic to have 'allow-opts' included then even outdated Linux based devices are completely safe behind your OPNsense/FreeBSD based Firewall ?

If so : VERY COOL! :)

[paepcke]

IP options are ok!

cve-2026-98432 is about tcp handshake (syn) and associated tcp options in the tcp header

The problem is: The FreeBSD pf firewall is able to track tcp session state, but has from my understanding currently no interface to investigate and normalize tcp header anomalies.

Thats a problem. For this specific CVE and in general for the fast moving ai driven exploit market.

[Monviech (Cedrik)]

Maybe open a ticket upstream if you feel like something is missing that you need.

https://bugs.freebsd.org/bugzilla/enter_bug.cgi?product=Base%20System

But from what I read here its about IP Options, and not TCP options, but maybe I misunderstand something.

https://access.redhat.com/security/vulnerabilities/RHSB-2026-016
Filter Incoming IPv4 Packets Containing IP Options
The following nftables table drops incoming IPv4 TCP packets that contain IP options, which reduces exposure to this vulnerability but cannot fully prevent it. Ordinary application traffic is generally expected to remain unaffected, because standard TCP options are carried in the TCP header and continue to be permitted.

[abulafia]

AI recommended to enable "synproxy" state handling for incoming traffic to those Linux servers. The TCP SYN session should then terminate at OPnsense and a clean TCP stream go from OPnsense to the server.

Alternatively (better?) use a reverse proxy on OPnsense. That definitely terminates the TCP connection at OPnsense, which as a BSD system is not affected by this Linux bug.

[meyergru]

Alternatively (better?) use a reverse proxy on OPnsense. That definitely terminates the TCP connection at OPnsense, which as a BSD system is not affected by this Linux bug.

...creating new security threats in the process.

[Manfred.Knick]

- does impact every Linux ...

This is plain wrong.

The original Anthropic publication states:
"This vulnerability (CVE-2026-98432) was patched upstream and backported to all maintained stable kernel branches."

Linus' wording: "It's a bug. Fix it!"

Already at publication 2026-10-15, the original CVE-2026-98432 listed
all the longterm and stable kernel versions being unaffected.
Kernel developers had fixed upstream 10 days before
(October 5, commit e3f33b0a1d89).

Since October 11, four days before publication time,
I was already running a patched kernel (gentoo-sources-7.2.10).

Up to November 1st., the big distributions had provided their patches.

RedHat, RHSB-2026-016, section 'Mitigation':

"Filtering ... is not a substitute for patching.
Applying kernel security updates ... is the only complete solution ... "

Until today, no entry has arrived into the CISA Known Exploited Vulnerabilities Catalog.

. . . creating new security threats in the process.

@ Uwe: +1 !

No, The world is not coming to an end.
Nobody should get enticed into swinging an un-tested big bat
introducing un-foreseen consequences' harm.

Stay vigilant, stay safe -
I allow myself to question the real intention behind any post
advertising "Security Advisories" instead of citing cve.org directly.

[paepcke]

From my understanding the bug itself (a very rare race condition in the ip option set multiprocessing handling) is useless without further down the road support via more flexible tcp header options.

The full working exploit chain  requirements are not disclosed yet - for obvious reasons - but the Anthropic sample exploit seems to need mptcp enabled tcp services and tcp options support for the 2nd step, thats why all current more complex IDS rules targeting tcp.

Simply blocking ALL ip-options seems to be right choice here - after a review of the corresponding RFCs that define most of the prehistoric use cases.

Thanks for the qualified Feedback!

OPNsense/pf seems to be well equipped for the coming CVE-2026-98432 Linux Apocalypse. No need to inspect the tcp options in this case.