Howdy, Stranger!

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


Shells Virtual Desktop
BMail.ag - Secure Email Service
Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
InterServer VPS
BMail.ag - Secure Email Service
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
Residential IPs in the US & 4G Mobile Proxies in EU & US with Unlimited Bandwidth
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
Shells Virtual Desktop
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.

Dirty Frag: Universal Linux LPE

2

Comments

  • NeoonNeoon Community Contributor, Veteran

    @jfrac said:
    VM escape 0-day when?

    ha funny guy.
    If you are good, the VM runs as different user.
    Well then yet again, a local prev exploit could fuck you.

  • woinokizwoinokiz Member

    What's safe nowadays?

  • forestforest Member

    @Neoon said:

    @jfrac said:
    VM escape 0-day when?

    ha funny guy.
    If you are good, the VM runs as different user.
    Well then yet again, a local prev exploit could fuck you.

    The hypervisor has kernel components that can and do get exploited from time to time. After all, many instructions that trap #vmexit are emulated within the kernel. That's ring 0.

    Thanked by 1tentor
  • Tony40Tony40 Member

    AlmaLinux OS: Dirty Frag vulnerability fix is ready for testing

    https://almalinux.org/blog/2026-05-07-dirty-frag/

  • OhJohnOhJohn Member

    Thank god it's friday? Again?

    Damn, last week 100 kernel updates and reboots (while the ubuntu repos were ddosed), now the same shit again starting the second updates are out and in October we will be at 6.8.0.480?

    Boss, I'm calling in sick. It's sunny outside.

    Thanked by 1oloke
  • dbadudedbadude Member
    edited May 8

    @ScreenReader said: there has to be a way to blacklist all unused modules if the vps are just being used for a wireguard tunnel, ping probe or something, anyone ever made this kind of list?

    sysctl -w kernel.modules_disabled=1
    

    That will prevent loading and unloading of new modules that aren't already loaded.

    Yeah good idea to lock the backdoor of the chicken house.

  • yakoudevyakoudev Member

    sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

    i'am using this for patch. when i test again is already patched

  • AnaisAnais Member

    Looking forward to a great weekend :#

  • FatGrizzlyFatGrizzly Member, Host Rep
    edited May 8

    @woinokiz said:
    What's safe nowadays?

    Windows Server 2003.

    Solid. No LPE's or vulnerabilities in the wild

    /s

    Thanked by 1tentor
  • OhJohnOhJohn Member
    Thanked by 1allthemtings
  • allthemtingsallthemtings Member, Megathread Squad

    end is near.gif

  • Carlin0Carlin0 Member

  • AndreixAndreix Member, Host Rep

    A long shot... but... maybe... all those disclosures have anything to do with the uber-announced Claude Mythos?!

  • OhJohnOhJohn Member

    ok, 45 minutes later it is not a 404 anymore. So it's time to look out for a working mirror to be prepared.

  • @jfrac said:
    VM escape 0-day when?

    Far too valuable to drop publicly. LPEs are common so they have little value to exploit brokers, which is why they get dropped publicly for internet credit, but a decent VM escape is worth $250,000+ so they're rarely even reported to the vendors.

  • mustafamw3mustafamw3 Member, Patron Provider, LIR

    For anyone concerned about the Dirty Frag issue, first check whether the affected modules are even loaded before applying mitigations.

    grep -E '^(esp4|esp6|rxrpc) ' /proc/modules
    

    If the command returns nothing, those modules are not currently loaded on your system.

    Most normal web hosting servers (Plesk/WHMCS/LAMP/etc.) likely won’t have them loaded unless using IPsec/VPN related features.

    In that case, there’s usually no urgent need for the temporary module mitigation, though you should still install kernel security updates once available.

  • forestforest Member
    edited May 9

    @mustafamw3 said:
    For anyone concerned about the Dirty Frag issue, first check whether the affected modules are even loaded before applying mitigations.

    grep -E '^(esp4|esp6|rxrpc) ' /proc/modules
    

    If the command returns nothing, those modules are not currently loaded on your system.

    Most normal web hosting servers (Plesk/WHMCS/LAMP/etc.) likely won’t have them loaded unless using IPsec/VPN related features.

    In that case, there’s usually no urgent need for the temporary module mitigation, though you should still install kernel security updates once available.

    It doesn't matter if they're not currently loaded. The problem is that they will be autoloaded.

    I tested this myself.

  • default# grep -E '^(esp4|esp6|rxrpc) ' /proc/modules
    grep: /proc/modules: No such file or directory
    

    What now?

  • forestforest Member

    @totally_not_banned said:

    default# grep -E '^(esp4|esp6|rxrpc) ' /proc/modules
    grep: /proc/modules: No such file or directory
    

    What now?

    Assuming you're getting that because you have CONFIG_MODULES=n, then:

    grep -E '^CONFIG_(AF_RXRPC|XFRM_ESP)=y$' /boot/config-$(uname -r)
    
  • @forest said:

    @totally_not_banned said:

    default# grep -E '^(esp4|esp6|rxrpc) ' /proc/modules
    grep: /proc/modules: No such file or directory
    

    What now?

    Assuming you're getting that because you have CONFIG_MODULES=n, then:

    grep -E '^CONFIG_(AF_RXRPC|XFRM_ESP)=y$' /boot/config-$(uname -r)
    
    default# grep -E '^CONFIG_(AF_RXRPC|XFRM_ESP)=y$' /boot/config-$(uname -r)
    grep: /boot/config-9.3: Not a directory
    

    :(

  • forestforest Member
    edited May 9

    @totally_not_banned said:

    @forest said:

    @totally_not_banned said:

    default# grep -E '^(esp4|esp6|rxrpc) ' /proc/modules
    grep: /proc/modules: No such file or directory
    

    What now?

    Assuming you're getting that because you have CONFIG_MODULES=n, then:

    grep -E '^CONFIG_(AF_RXRPC|XFRM_ESP)=y$' /boot/config-$(uname -r)
    
    default# grep -E '^CONFIG_(AF_RXRPC|XFRM_ESP)=y$' /boot/config-$(uname -r)
    grep: /boot/config-9.3: Not a directory
    

    :(

    zgrep -E '^CONFIG_(AF_RXRPC|XFRM_ESP)=y$' /proc/config.gz
    

    Edit: "9.3" wut. What's your uname -s m8

  • edited May 9

    @forest said:

    @totally_not_banned said:

    @forest said:

    @totally_not_banned said:

    default# grep -E '^(esp4|esp6|rxrpc) ' /proc/modules
    grep: /proc/modules: No such file or directory
    

    What now?

    Assuming you're getting that because you have CONFIG_MODULES=n, then:

    grep -E '^CONFIG_(AF_RXRPC|XFRM_ESP)=y$' /boot/config-$(uname -r)
    
    default# grep -E '^CONFIG_(AF_RXRPC|XFRM_ESP)=y$' /boot/config-$(uname -r)
    grep: /boot/config-9.3: Not a directory
    

    :(

    zgrep -E '^CONFIG_(AF_RXRPC|XFRM_ESP)=y$' /proc/config.gz
    

    Edit: "9.3" wut

    default# zgrep -E '^CONFIG_(AF_RXRPC|XFRM_ESP)=y$' /proc/config.gz
    -sh: zgrep: not found
    

    No luck either :(

  • edited May 9

    @forest said:
    What's your uname -s m8

    default# uname -s
    NetBSD
    

    Is that good or bad? ;)

  • forestforest Member

    @totally_not_banned said:

    @forest said:
    What's your uname -s m8

    default# uname -s
    NetBSD
    

    Is that good or bad? ;)

    Well, you aren't affected by DirtyFrag, but NetBSD's security track record is not so great anyway. ;)

    Thanked by 1totally_not_banned
  • @forest said:

    @totally_not_banned said:

    @forest said:
    What's your uname -s m8

    default# uname -s
    NetBSD
    

    Is that good or bad? ;)

    Well, you aren't affected by DirtyFrag

    Pheeeewww :D

    but NetBSD's security track record is not so great anyway. ;)

    Yeah, thats sadly true. I love the system but lack of manpower is quite the euphemism when it comes to the overall project.

  • forestforest Member

    @totally_not_banned said: Yeah, thats sadly true. I love the system but lack of manpower is quite the euphemism when it comes to the overall project.

    Switch to DragonflyBSD! It'll be the Year of the HAMMER2 Filesystem™ any day now!

  • @forest said:

    @totally_not_banned said: Yeah, thats sadly true. I love the system but lack of manpower is quite the euphemism when it comes to the overall project.

    Switch to DragonflyBSD! It'll be the Year of the HAMMER2 Filesystem™ any day now!

    Hahaha, if they manage to do it before NetBSD implements 802.11n i might think about it ;)

    Thanked by 1forest
  • mustafamw3mustafamw3 Member, Patron Provider, LIR
    edited May 9

    @forest said:

    @mustafamw3 said:
    For anyone concerned about the Dirty Frag issue, first check whether the affected modules are even loaded before applying mitigations.

    grep -E '^(esp4|esp6|rxrpc) ' /proc/modules
    

    If the command returns nothing, those modules are not currently loaded on your system.

    Most normal web hosting servers (Plesk/WHMCS/LAMP/etc.) likely won’t have them loaded unless using IPsec/VPN related features.

    In that case, there’s usually no urgent need for the temporary module mitigation, though you should still install kernel security updates once available.

    It doesn't matter if they're not currently loaded. The problem is that they will be autoloaded.

    I tested this myself.

    Correct, but the modules still won’t load by themselves unless something actually requests that functionality first.

    On a typical web hosting server without IPsec/VPN usage, there usually isn’t anything triggering esp4, esp6, or rxrpc during normal operation.

    For extra hardening, if the modules are not loaded, you can temporarily do:

    sysctl -w kernel.modules_disabled=1
    

    This prevents loading any new kernel modules until reboot. Just remember to reboot normally once patched kernel updates are installed.

    Thanked by 1NetDynamics24
Sign In or Register to comment.