Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Linux Kernel TCP RCE CVE-2026-98432

2»

Comments

  • tuxtux Veteran

    There are updated kernel in proposed repo and also in kernel ppa if you want test it.

  • @yoursunny said:
    The flaw is a race condition in the code that sets up new IPv4 TCP connections.

    We disabled IPv4 long ago except on VirMach.
    VirMach hasn’t performed the Pwnscape reboot, so it can’t get worse.

    LOL, i think turning to ipv6 will give even world peace.

    Thanked by 1zed
  • yoursunnyyoursunny Member, IPv6 Advocate

    @dbadude said:
    i think turning to ipv6 will give even world peace.

    You are right to think about that.
    From the past to the present, most of the wars are triggered by shortages: shortage of land (American Indian Wars), shortage of oil (Japan in World War II), shortage of consumer spending (fast food value menu wars), shortage of IPv4 addresses (cloud giant hoarding wars).
    IPv6 is the most plentiful resource and can surely bring world peace.

  • pvumpvum Member

    It's time to switch to wireguard

  • Dear Ubuntu, why do I reboot today into a new kernel published today or yesterday while this new one is still not fixed? Debian fixed it two weeks ago...

  • SteveMCSteveMC Member
    edited October 30

    <3 <3 <3 Debian <3 <3 <3

  • LeviLevi Veteran

    How this can be exploited practicaly? Yet again, another fud spread?

  • tuxtux Veteran

    @OhJohn said:
    Dear Ubuntu, why do I reboot today into a new kernel published today or yesterday while this new one is still not fixed? Debian fixed it two weeks ago...

    There are fixed kernel in proposed repo and also in kernel ppa, if you want test it.

    Thanked by 1tzuli
  • NeoonNeoon Community Contributor, Veteran
    edited October 30

    @Levi said:
    How this can be exploited practicaly? Yet again, another fud spread?

    From what I read, its hard to exploit, probably only target attacks, nothing random.
    If its exploited, you cooked though.

    Thanked by 1tzuli
  • jfracjfrac Member, Host Rep

    Redhat updated their score to 9.8.

  • rdesrdes Member
    edited October 30

    And it's so critical that they not delivered fix for 15 days and still counting.

  • stable_geniusstable_genius Member
    edited October 30

    @rdes said:
    And it's so critical that they not delivered fix for 15 days and still counting.

    They are busy doing more advanced stuff, no time for that.

  • NeoonNeoon Community Contributor, Veteran

    @stable_genius said:

    @rdes said:
    And it's so critical that they not delivered fix for 15 days and still counting.

    They are busy doing more advanced stuff, no time for that.

  • The practical order here is inventory first: record the running kernel, the distro kernel package, and whether the guest or the host kernel is actually in scope, because that distinction matters a lot for LXC versus KVM. Patch from the distro vendor and reboot into the fixed kernel rather than relying on a workaround, and verify after reboot instead of assuming the package update alone was enough. While waiting for a vendor kernel, reduce exposure by firewalling public TCP listeners to only the addresses that truly need them and disabling MPTCP if it is not in use. Appliances and routers deserve a separate pass too, since they often lag behind servers and still expose a public TCP port.

  • @Jalarihala said:
    The practical order here is inventory first: record the running kernel, the distro kernel package, and whether the guest or the host kernel is actually in scope, because that distinction matters a lot for LXC versus KVM. Patch from the distro vendor and reboot into the fixed kernel rather than relying on a workaround, and verify after reboot instead of assuming the package update alone was enough. While waiting for a vendor kernel, reduce exposure by firewalling public TCP listeners to only the addresses that truly need them and disabling MPTCP if it is not in use. Appliances and routers deserve a separate pass too, since they often lag behind servers and still expose a public TCP port.

    Thanks SlopGPT.

  • the patched kernel is in testing now for almalinux, see https://almalinux.org/blog/2026-10-30-cve-2026-98432/

Sign In or Register to comment.