Apparently there's yet another #LinuxKernel Local Privilege Escalation #vulnerability.
-
Apparently there's yet another #LinuxKernel Local Privilege Escalation #vulnerability. There's a mitigation that disables esp4, esp6 and rxrpc modules.
GitHub - V4bel/dirtyfrag
Contribute to V4bel/dirtyfrag development by creating an account on GitHub.
GitHub (github.com)
EDIT: The related vulnerabilities are now tracked as CVE-2026-43284 and CVE-2026-43500. https://nvd.nist.gov/vuln/detail/CVE-2026-43284 https://nvd.nist.gov/vuln/detail/CVE-2026-43500
-
Apparently there's yet another #LinuxKernel Local Privilege Escalation #vulnerability. There's a mitigation that disables esp4, esp6 and rxrpc modules.
GitHub - V4bel/dirtyfrag
Contribute to V4bel/dirtyfrag development by creating an account on GitHub.
GitHub (github.com)
EDIT: The related vulnerabilities are now tracked as CVE-2026-43284 and CVE-2026-43500. https://nvd.nist.gov/vuln/detail/CVE-2026-43284 https://nvd.nist.gov/vuln/detail/CVE-2026-43500
@harrysintonen None of my #Debian #linux boxen have those kernel modules loaded:
sudo lsmod | egrep "esp4|esp6|rxrpc"
#InfoSec -
@harrysintonen None of my #Debian #linux boxen have those kernel modules loaded:
sudo lsmod | egrep "esp4|esp6|rxrpc"
#InfoSec@gtsadmin They will be loaded by the kernel automatically on demand. So apply the mitigation until kernel update is available.
-
Apparently there's yet another #LinuxKernel Local Privilege Escalation #vulnerability. There's a mitigation that disables esp4, esp6 and rxrpc modules.
GitHub - V4bel/dirtyfrag
Contribute to V4bel/dirtyfrag development by creating an account on GitHub.
GitHub (github.com)
EDIT: The related vulnerabilities are now tracked as CVE-2026-43284 and CVE-2026-43500. https://nvd.nist.gov/vuln/detail/CVE-2026-43284 https://nvd.nist.gov/vuln/detail/CVE-2026-43500
Note that if you tested the exploit locally and then applied the workaround your system will retain the tampered kernel cache and will remain vulnerable even when the module is no longer in memory and cannot no longer be loaded.
You can use sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" to flush the exploit from memory. Rebooting will also work, of course.
EDIT: Needless to say you should not execute random exploits in any important system. Always use a dedicated VM you can wipe after testing.
-
Note that if you tested the exploit locally and then applied the workaround your system will retain the tampered kernel cache and will remain vulnerable even when the module is no longer in memory and cannot no longer be loaded.
You can use sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" to flush the exploit from memory. Rebooting will also work, of course.
EDIT: Needless to say you should not execute random exploits in any important system. Always use a dedicated VM you can wipe after testing.
@harrysintonen In addition to Dirtyfrag, there there's Copy Fail 2 - Electric Boogaloo. https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo This sets up an ESP interface and exploits a bug in the ESP-in-UDP code.
Same here, probably prudent to drop caches (restart networking?) and remove the uid0 entry from /etc/passwd -
@harrysintonen In addition to Dirtyfrag, there there's Copy Fail 2 - Electric Boogaloo. https://github.com/0xdeadbeefnetwork/Copy_Fail2-Electric_Boogaloo This sets up an ESP interface and exploits a bug in the ESP-in-UDP code.
Same here, probably prudent to drop caches (restart networking?) and remove the uid0 entry from /etc/passwd@christopherkunz Sure if you executed that particular exploit you definitely must restore the /etc/passwd afterwards.
-
Apparently there's yet another #LinuxKernel Local Privilege Escalation #vulnerability. There's a mitigation that disables esp4, esp6 and rxrpc modules.
GitHub - V4bel/dirtyfrag
Contribute to V4bel/dirtyfrag development by creating an account on GitHub.
GitHub (github.com)
EDIT: The related vulnerabilities are now tracked as CVE-2026-43284 and CVE-2026-43500. https://nvd.nist.gov/vuln/detail/CVE-2026-43284 https://nvd.nist.gov/vuln/detail/CVE-2026-43500
@harrysintonen yesterday I read that one should not drop caches in a production system. I don’t know if that recommendation was just for performance or if all hell could break loose.
-
R relay@relay.infosec.exchange shared this topic