---

Introduction

In June 2024, a new vulnerability dubbed CVE-2024-53141 was identified and resolved in the Linux kernel’s netfilter subsystem, specifically in the ipset component. If left unpatched, attackers could potentially exploit this flaw to bypass ipset rules or make unauthorized modifications to IP sets.

This article will break down the technical issue, demonstrate the code involved, provide a step-by-step guide on how one could have exploited the bug, and, for those maintaining Linux systems, explain how to patch and protect your infrastructure.

What is ipset and the netfilter subsystem?

netfilter is the core framework in the Linux kernel for packet filtering, NAT, and other packet-mangling. ipset is a module allowing administrators to create sets of IPs, networks, or ports to implement fast matching inside netfilter.

Sets are manipulated via commands and used in iptables rules — an efficient way to handle complex firewall rules.

The Vulnerability: Missing Range Check in bitmap_ip_uadt

Affected Component:
bitmap_ip_uadt function inside the ipset kernel module.

TL;DR: When assigning a range of IPs to an ipset entry, if you give a CIDR block without explicitly specifying an end IP (IPSET_ATTR_IP_TO), ipset calculates the range boundaries from the starting IP and the size given by the CIDR. However, the code was missing a key range validation in this case, potentially allowing out-of-bounds memory accesses or logic errors.

IPSET_ATTR_CIDR — alternative size specification as a CIDR mask

When IPSET_ATTR_IP_TO is missing but IPSET_ATTR_CIDR is available, ip and ip_to are intentionally “swapped" — so the intended validation should also shift. Sadly, that check wasn't happening, allowing a user to specify out-of-range or invalid ipsets.

If an out-of-bound range was accepted, you could (for example) trick ipset/netfilter into mishandling traffic, or write entries outside the intended array, risking memory corruption in extreme cases (though full arbitrary code execution is unlikely).

Below is a simplified version of the flawed code (before the fix)

// In kernel/net/netfilter/ipset/ip_set_bitmap_ip.c

if (tb[IPSET_ATTR_IP_TO]) {
    ip_to = ip_set_get_h32(tb[IPSET_ATTR_IP_TO]);
    // Range check present here
    if (ip_to < ip || ip_to > last_ip)
        return -IPSET_ERR_BITMAP_RANGE;
} else if (tb[IPSET_ATTR_CIDR]) {
    cidr = ip_set_get_h8(tb[IPSET_ATTR_CIDR]);
    if (cidr > 32)
        return -IPSET_ERR_INVALID_CIDR;
    ip_to = ip | ~ip_set_mask_from_cidr(cidr); // ip_set_mask_from_cidr returns mask for CIDR
    // MISSING: No range check here!
}

Here's how the code SHOULD handle both cases, with the missing range check added

if (tb[IPSET_ATTR_IP_TO]) {
    ip_to = ip_set_get_h32(tb[IPSET_ATTR_IP_TO]);
    if (ip_to < ip || ip_to > last_ip)
        return -IPSET_ERR_BITMAP_RANGE;
} else if (tb[IPSET_ATTR_CIDR]) {
    cidr = ip_set_get_h8(tb[IPSET_ATTR_CIDR]);
    if (cidr > 32)
        return -IPSET_ERR_INVALID_CIDR;
    ip_to = ip | ~ip_set_mask_from_cidr(cidr);

    // ADDED: Proper range check!
    if (ip > ip_to || ip_to > last_ip)
        return -IPSET_ERR_BITMAP_RANGE;
}

Patch Reference

Exploiting the Vulnerability

NOTE: This is for educational and remediation purposes only. Do not exploit systems you do not own or have explicit authorization to test.

Let’s say an admin creates a bitmap:ip type ipset

ipset create myset bitmap:ip range 10...-10...255

A normal addition

ipset add myset 10...42

With the vulnerability, you could try to add an IP range using only IP and CIDR, but select a start IP that, when combined with the CIDR, exceeds the set range's boundaries. With the missing range check, this would be accepted by the kernel when it should be rejected.

Example Exploit Code (using libipset)

#include <libipset/ipset.h>

int main() {
    struct ipset_session *session = ipset_session_init(NULL);
    ipset_session_printf(session, "add myset 10...250/30\n");
    ipset_session_commit(session);
    ipset_session_fini(session);
    return ;
}

In pre-patched kernels, this might allow the addition of entries that should have been outside "myset"'s range. Subsequent firewall logic may become unpredictable.

Traffic misclassification: Firewall or NAT rules can behave unexpectedly.

- Possible kernel memory corruption: In theory, depending on kernel allocations, out-of-bounds writes could cause a panic or rare deeper security risks.
- Privilege escalation: There's no direct evidence of reliable privilege escalation, but logic bugs in the network stack are always high-impact.

Mitigation & Fix

Patched in Linux mainline: See commit efcb9a1f1dc3.

How to patch

- If you maintain your own kernel builds: cherry-pick the patch or update to a version after the patch date (June 12, 2024).
- If using a vendor distribution: Watch for CVE-2024-53141 in update channels, and apply any offered security updates.

Mitigation:

Restrict access to ipset manipulation to only trusted users.

- Audit your ipset entries for ranges/CIDRs that do not make sense.

Conclusion

CVE-2024-53141 highlights how even in mature code, a small missing validation can open the door to subtle security bugs. For sysadmins and developers working with Linux netfilter, ensure your kernels stay updated, especially for components that directly impact your firewall and network controls.

References

- Kernel Patch Commit
- ipset man page
- Linux netfilter overview
- CVE-2024-53141 Entry (will update when assigned)

Timeline

Published on: 12/06/2024 10:15:06 UTC
Last modified on: 12/14/2024 21:15:38 UTC