Keepalived contains an integer‑overflow bug in the VRRP ipset parsing code that was tracked as CVE‑2024‑41184; the flaw can be triggered by an empty ipset name in configuration, can produce undefined reads or crashes, and was patched upstream by adding strict validation so malformed or empty ipset names cause a configuration error rather than unsafe memory arithmetic.
Keepalived is a long‑standing open‑source daemon used to implement VRRP-based high‑availability and to drive simple health checks and load‑balancing logic on Linux hosts. Its VRRP configuration supports optional ipset references (the vrrp_ipsets keyword) so that operators can combine VRRP failover logic with firewall rulesets and traffic classification. In July 2024 a vulnerability was published (CVE‑2024‑41184) that affects keepalived releases through 2.3.1: the parser that handles the vrrp_ipsets configuration could perform integer arithmetic that underflows when presented with an empty ipset name, leading to out‑of‑bounds reads and other undefined behaviour. Multiple vendors and vulnerability databases cataloged the issue and several distributions shipped fixes or backports.
Why this matters operationally: keepalived commonly runs on edge load‑balancers, appliance hosts, and HA proxies — places where availability is critical. A malformed configuration or specially crafted input that reaches vulnerable code paths can produce either a crash of the keepalived process or read memory it ought not to, creating an availability impact and, in worst cases, a pathway to additional exploitation depending on environment specifics and downstream processing. Several distributors produced advisories and patched packages; upstream keepalived added validation to reject empty ipset names rather than accept them and continue.
empty ipset names and return a config error." Several downstream distributions incorporated the upstream change or equivalent validation patches into their packages (Red Hat, SUSE, AlmaLinux and others produced backports and named patches).
Key validation points:
If you manage appliances or appliances images that embed keepalived, treat this as a priority patch-and-validate item: apply the vendor fixed package, rebuild images where necessary, and add configuration validation to your deployment pipeline so the same category of bug cannot reappear. Finally, when a vulnerability is flagged as “low priority” by some vendors because a misconfiguration is required, don’t mistake that for “no action required” — automated deployments, templating engines, and multi‑tenant management planes are where unusual configuration states become real exposure, and those systems deserve the highest scrutiny.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
Keepalived is a long‑standing open‑source daemon used to implement VRRP-based high‑availability and to drive simple health checks and load‑balancing logic on Linux hosts. Its VRRP configuration supports optional ipset references (the vrrp_ipsets keyword) so that operators can combine VRRP failover logic with firewall rulesets and traffic classification. In July 2024 a vulnerability was published (CVE‑2024‑41184) that affects keepalived releases through 2.3.1: the parser that handles the vrrp_ipsets configuration could perform integer arithmetic that underflows when presented with an empty ipset name, leading to out‑of‑bounds reads and other undefined behaviour. Multiple vendors and vulnerability databases cataloged the issue and several distributions shipped fixes or backports.Why this matters operationally: keepalived commonly runs on edge load‑balancers, appliance hosts, and HA proxies — places where availability is critical. A malformed configuration or specially crafted input that reaches vulnerable code paths can produce either a crash of the keepalived process or read memory it ought not to, creating an availability impact and, in worst cases, a pathway to additional exploitation depending on environment specifics and downstream processing. Several distributors produced advisories and patched packages; upstream keepalived added validation to reject empty ipset names rather than accept them and continue.
Technical summary: what the bug is and how it triggers
Root cause (in plain terms)
The vulnerable code path lives in the VRRP configuration parser inside fglobal_parser.c, in the function that handles vrrp_ipsets declarations. When parsing ipset names the code computed lengths and then used an expression equivalent to len - 1 to index or allocate memory. If the ipset name string length is zero, that subtraction underflows (because type is unsigned such as size_t), producing a very large value that leads to a read or allocation with an incorrect size. The result is undefined behaviour: out‑of‑bounds reads, crashes, or other misbehaviour. Multiple public trackers and vendor advisories describe the same arithmetic underflow pattern.Conditions required to exploit
- The keepalived binary must be running a vulnerable version (up to and including 2.3.1).
- The vulnerable handler is reached only when the VRRP configuration contains a vrrp_ipsets entry; in practice, the user (operator) must have configured ipset names — including the empty name case — for the problematic arithmetic to run.
- Many trackers note the same mitigating nuance: an empty ipset name (a misconfiguration) must be present for the immediate trigger, which reduces accidental exposure but does not eliminate attackability in misconfigured or automated environments.
Observable outcomes
- Process crash / denial of service: the most immediate and reliable outcome when the arithmetic yields an invalid pointer or indexing is that keepalived will crash or abort — causing loss of the VRRP service and any dependant virtual IPs.
- Memory disclosure: depending on how the reader/writer code is used after the underflow, the behavior could include reading memory beyond the intended buffer; some database trackers flagged confidentiality and integrity impacts in high‑score assessments, though real exploitation to exfiltrate secrets or chain to code execution is environment‑dependent and not universally proven in public PoCs.
How vendors scored and described the risk
Vendor and community trackers diverged somewhat in tone because of the prerequisite that an empty ipset name be present.- Several public CVSS feeds (including the canonical upstream capture) listed high or critical base scores (for example, a 9.8 CVSS v3.1 base score appeared in some aggregated feeds), reflecting the potential for high confidentiality/integrity/availability impact if the condition were met. Those scorings assume remote exposure and trivial triggering once the invalid config exists.
- Distribution maintainers and security teams often lowered practical priority because the exploit requires an invalid configuration (empty ipset name), which is unlikely in well‑managed environments. Ubuntu explicitly notes the need to configure an empty ipset name and judged the priority accordingly. Red Hat and SUSE bundled fixes in patched packages for their supported release lines to remove the problem on their images.
Upstream fix and timeline
Upstream keepalived resolved the problem by enforcing validation for ipset names: empty ipset names are explicitly rejected during configuration parsing and cause a configuration error rather than being accepted and processed. This fix is recorded in upstream commits and is reflected in the keepalived 2.3.2 release notes where the project states it now "handleKey validation points:
- Upstream release that includes the change: keepalived 2.3.2 (release notes explicitly reference handling empty ipset names).
- Distribution backports: Red Hat, SUSE, and other vendors shipped patched keepalived packages in their advisories, and some distributions implemented additional validation patches or version‑specific backports. Administrators should consult their distro advisory for the exact fixed package version.
Cross‑referencing and verification
I verified the core technical claims against multiple independent sources to avoid single‑source dependence:- Canonical vendor advisory and tracking: Ubuntu’s security page and the aggregated CVE records describe the same underflow condition and explicitly note the empty ipset prerequisite.
- Upstream project: keepalived release notes (2.3.2) show the explicit addition of empty‑ipset validation and config errors. That upstream commit is the primary remediation action.
- Distribution advisories and backports: Red Hat and SUSE advisories list fixed package versions and include the security fix descriptions; AlmaLinux and other enterprise distros produced patches that reference the upstream commit.
Practical mitigation and remediation guidance (what admins should do now)
If you operate keepalived anywhere in your estate, treat this as a routine but important patch-and-validate item. The following is a prioritized action checklist you can implement today.1) Inventory and identify exposures (immediate)
- Enumerate machines and containers running keepalived and record the exact package versions or upstream binary version output. Use your configuration management / package inventory or run keepalived --version where safe.
- Identify hosts that use VRRP and, specifically, VRRP configurations that include any ipset usage (the vrrp_ipsets keyword). Those are the only configurations that exercise the affected code path.
2) Short‑term mitigations (minutes to hours)
- If updating immediately is not possible, inspect all keepalived configuration files for vrrp_ipsets entries and ensure no entry contains an empty ipset name. If any exist, remove or correct them now.
- Consider temporarily disabling keepalived or taking affected VRRP instances out of service if you cannot confirm configuration correctness and cannot patch quickly. Prioritize non‑redundant edge appliances where keepalived failure has the biggest application impact.
- Apply network controls (ACLs, host firewalls) to restrict access to management networks that could push or rely on fraudulent configurations in automated orchestration systems.
3) Patch (days)
- Upgrade keepalived to a version that includes the fix (upstream: 2.3.2 or later) or install your vendor’s patched package. Confirm the presence of the upstream commit or the distribution advisory entry before marking a host as remediated.
4) Validation and post‑patch checks
- After upgrading, revalidate your VRRP configs and restart keepalived in a controlled maintenance window. Confirm that invalid ipset declarations now produce configuration errors (this is expected behaviour).
- Monitor supervision logs, systemd, or the orchestration layer for keepalived restarts or crashes for several days after patching to detect any latent issues introduced by configuration changes.
5) Hardening and process changes (weeks to months)
- Add config‑linting to your deployment pipelines: treat empty values for network objects as errors and fail CI checks.
- Enforce code and configuration reviews for network control plane changes; a simple mis-typed key/value in a VRRP block should not be able to take a service offline.
- Where keepalived runs as part of an appliance image or a managed service image, ensure your image build pipeline consumes the fixed package and that rebuilds are rolled out in a predictable maintenance cadence. Several downstream vendors already published fixed package versions — consult vendor advisories for exact version numbers.
Detection and hunting guidance
If you have large fleets or are concerned about silent misconfigurations, hunting for signs of attempted or successful exploitation is useful:- Search your configuration management repositories for vrrp_ipsets entries that are blank or that might be templated to empty values in certain environments (automation templating bugs commonly create empty strings).
- Look for recent keepalived crashes or unexpected restarts in system logs (journalctl /var/log/syslog) around the time when configuration pushes occurred.
- Monitor for anomalous control‑plane operations in orchestration systems (for example, CI jobs or config‑push pipelines that may have injected malformed VRRP snippets).
- If you operate a managed environment that ingests external configuration snippets, tighten validation at the ingestion point so invalid ipset names are rejected before they can be committed to production.
Risk analysis — strengths and residual risk
Strengths of the response
- Upstream was pragmatic: rather than attempt complicated bounds arithmetic workarounds, the project added conservative validation to reject empty ipset names. That eliminates the unsafe path entirely and is a lower‑risk code change.
- Major distributions took the fix seriously; Red Hat, SUSE, Ubuntu and others expressed remediation and shipped backported packages for supported release lines. Vendors that ship keepalived as part of appliance stacks produced their own advisories and patches.
Residual and contextual risks
- Human/automation error remains the primary concern: misconfiguration or automated config templating that accidentally produces empty strings is exactly the operational scenario that will re‑expose vulnerable behaviour on unpatched nodes.
- Vendor packaging lag: some environments use vendor‑maintained long‑term images or custom appliance images that may not receive immediate backports; those must be inventoried and patched proactively. Distribution advisories differ on the exact fixed package names and backport policy — administrators must not assume a blanket fix across all their images.
- Exploit chaining: while the immediate impact is DoS via crash, in some contexts uncontrolled reads or memory corruption can be used as a primitive in multi‑stage attacks. Public evidence for reliable remote code execution via this specific bug is limited; therefore claims of RCE based solely on CVE‑2024‑41184 should be treated with caution until demonstrated by a reliable PoC.
Advice for vendors, appliance builders and cloud operators
- Treat configuration‑parsing code like a parser for external input — apply the same defensive rigor as you would for packet parsers.
- Add automated config validation into image build pipelines so templates that might evaluate to empty strings are rejected before they reach production images.
- Provide clear VEX/CSAF attestations for product bundles that include keepalived so downstream customers can quickly determine whether their managed images are affected.
- Where possible, provide time‑boxed, automatic image rebuilds that include security updates for critical control‑plane components such as keepalived; document the exact package and version mappings for reproducibility. Several vendors have already followed that path in their advisories.
Conclusion
CVE‑2024‑41184 is a reminder that small mistakes in configuration parsing — an off‑by‑one, a subtraction from an unsigned length, or acceptance of empty strings — can escalate into service outages in critical parts of the network control plane. The good news is that the upstream keepalived project applied a minimal, robust fix (reject empty ipset names), and major distributions shipped backports or updated packages. The pragmatic operational takeaway is straightforward and urgent: inventory keepalived installations, verify whether any VRRP ipset configurations exist (watch for empty values), and upgrade to package versions that incorporate the upstream validation. Where upgrades cannot be immediate, remove empty ipset entries and add config linting to your automation so a templating bug cannot silently enable the vulnerable path.If you manage appliances or appliances images that embed keepalived, treat this as a priority patch-and-validate item: apply the vendor fixed package, rebuild images where necessary, and add configuration validation to your deployment pipeline so the same category of bug cannot reappear. Finally, when a vulnerability is flagged as “low priority” by some vendors because a misconfiguration is required, don’t mistake that for “no action required” — automated deployments, templating engines, and multi‑tenant management planes are where unusual configuration states become real exposure, and those systems deserve the highest scrutiny.
Source: MSRC Security Update Guide - Microsoft Security Response Center
