Top
Best
New

Posted by oger 6 hours ago

TCP Use-After-Free: CVE-2026-98432 / CVSS 9.8(atlasum.net)
303 points | 145 commentspage 3
daemonologist 5 hours ago|
Some previous discussion: https://news.ycombinator.com/item?id=50299182
lakeviewterrace 4 hours ago||
The linked source spun up my fans with 100% GPU utilization. Is there some... unwelcome... script running?
api 5 hours ago||
2027 is going to be the year of two to three major CVEs per day.

The discourse on this is weird, sounds at times as if these are “because of AI.” These are mostly pre-existing bugs, some very old, and they’ve been lurking. If they all get found we exit the other side more secure and reliable.

wry_xy 3 hours ago||
I went on a security kick early this year, locking down everything as much as I could. Build your systems with the assumption that you WILL get hacked. Limit blast radius. Be prepared.

The next few years will be crazy, but you're right, we'll come out the other side more secure than ever before. Just gotta make it that far!

jijijijij 2 hours ago||
Will be interesting to see, if AI will cause an increased demand for sysadmins. Not sure companies will go "Make no mistakes" on their (production) infrastructure.
jstanley 3 hours ago|||
> If they all get found we exit the other side more secure and reliable.

I agree, but as yet we have no idea how much pain we have to pass through to get to the other side.

Gigachad 3 hours ago||
On the other side we have a Linux networking stack written in Rust.
0xbadcafebee 2 hours ago||
The most terrifying part of this is all the devices that might be affected. Ignore servers and desktops. Linux 4.4 came out nearly 11 years ago. While most Linux devices' firmware is actually more ancient than that (Linux 2.x and 3.x isn't uncommon), any device that did ship with Linux 4.4+ is going to get hacked, because nobody patches those devices. Any smart device in the world that isn't a server, desktop, or microcontroller, is probably running Linux.

As part of the Software Building Code (that we don't have, and desperately need), one of the things we should have is mitigation for these abandoned internet safety risks. Here's how I would define that section:

  Section 4    Connections to Public Internet
  Section 4.1  Device Support
    Devices connected to the public internet WILL require one of the following:
      a) Guaranteed LTS support for a minimum of 10 years
      b) Guaranteed rolling release support for a minimum of 10 years
    Devices without this support are not permitted to be connected to the public internet.
  Section 4.2  Vendor Responsibility
    When releasing devices, vendors must determine whether this device is certified for
    public internet use. Support must be maintained according to S4.1. Failure to comply will
    result in fines of up to $5,000 per affected device.
  Section 4.3  Installer Responsibility
    Any device connected to the public internet which is not certified for public internet
    use is in violation, and will be subject to fines of up to $500 per affected device.
  Section 4.4  Device Owner Responsibility
    Any installed devices will be replaced once they reach their End Of Life period,
    or after 10 years, whichever comes first. Installed devices in use that exceed this
    period are in violation, and subject to fines of up to $250 per affected device.
(These fines are tiny compared to the fines for things like fire code violations, but enough money that a company, contractor, or individual would rather fix their device than pay the fines)
oger 6 hours ago||
MikroTik routers seem affected but mitigations are available.

Watch your Linux systems for kernel updates. Reboot!

tgv 5 hours ago|
If you use sysctl to disable mptcp, you need to do that again after each reboot.
jmclnx 5 hours ago||
If I am reading this right, Slackware 15.0 is already fixed:

     % uname -a
     Linux XXXX 5.15.223 #1 SMP PREEMPT Thu Oct 22 00:03:07 CDT 2026
     x86_64 Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz GenuineIntel GNU/Linux
cyberpunk 4 hours ago|
You’re still on slackware? I’ve not thought about it in years! How’re things over there?
tosti 3 hours ago||
It works mostly fine, pretty easy to work with, might perform well when you're sleeping / not around, packages are old (not neccesarily a bad thing). The default kernel is vintage 5.15, so just compile your own. Also elilo really sucks so bring your own bootloader while you're at it.
voidfunc 5 hours ago||
Oh joy.
jonathanstrange 3 hours ago||
I tried to find a mitigation using a ufw filter that rejects IPv4 packets with too large headers but it didn't work. It broke something essential and I had to switch it off again. I'd be interested in hearing about a temporary mitigation using firewall rules.
superkuh 38 minutes ago|
Add the below rule onto your machine's /etc/ufw/before.rules to mitigate it.

    # CVE-2026-98432 mitigation: drop TCP packets carrying IPv4 extended options
    -A ufw-before-input -p tcp -m u32 --u32 "0>>24&0xF=6:15" -j DROP
Any value >5 in this field means ip extended header options and so values of 6 through 15 should be dropped. Note that I don't just drop syn packets like the mptcp exploit because any tcp packet could do it in theory.

This works for me on multiple servers and home desktops and my hardware linux firewall/router. I did it a couple days ago when this was first announced. The iptables counter for matches haven't gone up at all on my VPS servers that gets lots of traffic. The counter only goes up when I manually trigger it to test. Everything continues to work nominally with these in place.

dofm 3 hours ago|
[06:00]
More comments...