Recent Kernel exploits, attack surface reduction, example IPSEC

birdculture1 pts0 comments

oss-security - Recent Kernel exploits, attack surface reduction, example IPSEC

Products

Openwall GNU/*/Linux server OS<br>Linux Kernel Runtime Guard<br>John the Ripper password cracker

Free & Open Source for any platform<br>in the cloud<br>Pro for Linux<br>Pro for macOS

Wordlists for password cracking<br>passwdqc policy enforcement

Free & Open Source for Unix<br>Pro for Windows (Active Directory)

yescrypt KDF & password hashing<br>yespower Proof-of-Work (PoW)<br>crypt_blowfish password hashing<br>phpass ditto in PHP<br>tcb better password shadowing<br>Pluggable Authentication Modules<br>scanlogd port scan detector<br>popa3d tiny POP3 daemon<br>blists web interface to mailing lists<br>msulogin single user mode login<br>php_mt_seed mt_rand() cracker

Services<br>Publications

Articles<br>Presentations

Resources

Mailing lists<br>Community wiki<br>Source code repositories (GitHub)<br>File archive & mirrors<br>How to verify digital signatures<br>OVE IDs

What's new

Follow @Openwall on Twitter for new release announcements and other news

[ [next>] [thread-next>] [day] [month] [year] [list]

Message-ID:<br>Date: Sat, 16 May 2026 15:05:45 +0200<br>From: Hanno Böck<br>To: oss-security@...ts.openwall.com<br>Subject: Recent Kernel exploits, attack surface reduction, example IPSEC

Hi,

Multiple of the recent kernel exploits have affected the "esp" Linux<br>Kernel module. ESP is, as far as I understand, part of IPSEC, and I<br>think it's fair to say that IPSEC is not widely used these days. I<br>think this raises some questions about attack surface. I want to note<br>that I use IPSEC as an example here, but it likely applies in very<br>similar ways to many features that are part of the Linux Kernel and are<br>not used in most common setups.

For everyone who builds custom kernels and doesn't use IPSEC, it's<br>probably a good idea to disable all IPSEC-related config options, e.g.:<br>CONFIG_INET_ESP<br>CONFIG_INET6_ESP<br>CONFIG_INET_AH<br>CONFIG_INET6_AH

I believe IPCOM is also rarely used separately from IPSEC, so consider<br>also disabling these:<br>CONFIG_INET_IPCOMP<br>CONFIG_INET6_IPCOMP

However, there's a broader point here: I think it's common these<br>days that Linux distributions install most or all kernel modules by<br>default, and loading them happens automatically. Which, in many cases,<br>means people are potentially affected by security flaws in features<br>they never use.<br>"Attack surface reduction" is widely considered to be a good security<br>principle, and I wonder if we can do better here.

To pick the example of IPSEC, i wonder if it wouldn't be better to<br>have, e.g., a separate "linux-modules-ipsec" package that isn't<br>installed by default. People who use and need IPSEC will likely know<br>that they need it, and can install it separately.

I'm aware this doesn't come for free, and will add increased<br>complexity to kernel packaging. But think about it like this: If we had<br>that separation, three of the recent kernel local root exploits would've<br>been much less impactful, and wouldn't have affected most systems.

Hanno Böck - Independent security researcher<br>https://itsec.hboeck.de/<br>https://badkeys.info/

Powered by blists - more mailing lists

Please check out the

Open Source Software Security Wiki, which is counterpart to this<br>mailing list.

Confused about mailing lists and their use?<br>Read about mailing lists on Wikipedia<br>and check out these<br>guidelines on proper formatting of your messages.

ipsec kernel linux security mailing recent

Related Articles