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.