Description

In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_hashlimit: validate hashtable supports XT_HASHLIMIT_RATE_MATCH The XT_HASHLIMIT_RATE_MATCH flag mode changes the semantics of the dsthash_ent structure which represents an entry in the hashtable. There is a union area which uses a different layout to express the rate match mode. Update .checkentry path to validate the XT_HASHLIMIT_RATE_MATCH mode flag is requested by two or more different rules that refer to the same hashtable. Otherwise, uninitialized access to the burst field in the union is possible. Reject the use of the XT_HASHLIMIT_RATE_MATCH mode flag if set on by revision less than 3 too.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-08-15T13:18:01.903Z",
  "pubdate": "2026-08-15T13:18:01.903Z",
  "executiveSummary": "A vulnerability has been identified in the Linux kernel netfilter subsystem, specifically within the xt_hashlimit module. The vulnerability involves improper validation of the XT_HASHLIMIT_RATE_MATCH flag mode when multiple rules reference the same hashtable.\nThe vulnerability type is uninitialized memory access, which can lead to information disclosure or unpredictable kernel behavior. The affected system is the Linux kernel utilizing the netfilter xt_hashlimit target.\nThe risk implications include potential kernel memory exposure or instability when conflicting rule configurations interact with shared hashtables. An attacker must possess sufficient privileges to configure netfilter rules (typically root or CAP_NET_ADMIN capabilities) to exploit this flaw.\nExploitation requires the ability to load iptables/netfilter rules and trigger the evaluation of hashlimit entries with mismatched rate match configurations. Mitigating this issue requires updating the kernel to include the validation check in the .checkentry path and rejecting the flag usage on revisions less than 3.",
  "technicalDetails": "The vulnerability resides in the netfilter xt_hashlimit module of the Linux kernel, specifically within the validation logic of the hashtable checkentry path. The affected component is responsible for managing rate-limiting rules and their associated hashtable entries represented by the dsthash_ent structure.\nThe root cause of the vulnerability is the absence of validation when the XT_HASHLIMIT_RATE_MATCH flag mode is requested. The XT_HASHLIMIT_RATE_MATCH flag alters the semantics of the dsthash_ent structure by utilizing a union area with a different layout designed to express the rate match mode.\nWhen multiple distinct rules reference the same hashtable but inconsistently request or omit the XT_HASHLIMIT_RATE_MATCH flag, structural mismatches occur within the shared hashtable entries. Specifically, this inconsistency can lead to uninitialized access to the burst field residing within the union area of the dsthash_ent structure.\nThe attack flow proceeds as follows: An attacker with administrative privileges or the capability to manipulate netfilter rules defines multiple iptables rules referencing a shared hashlimit table. At least one rule applies the XT_HASHLIMIT_RATE_MATCH flag while another does not, or uses an incompatible revision.\nBecause the .checkentry path previously failed to validate that all rules sharing a single hashtable consistently support or reject XT_HASHLIMIT_RATE_MATCH, the kernel accepts the conflicting configuration. Furthermore, the module fails to reject the use of the XT_HASHLIMIT_RATE_MATCH flag when set on revisions less than 3.\nWhen network packets traverse the netfilter hooks and trigger the evaluation of the affected hashlimit entries, the kernel attempts to read the burst field from the union area using the rate match layout. Due to the conflicting rule setup, this memory area may be uninitialized or improperly interpreted.\nThis results in uninitialized memory access, potentially leaking kernel stack or heap data to userspace depending on how the field is processed, or causing unpredictable kernel execution states. Authentication and privilege requirements include administrative access or the CAP_NET_ADMIN capability required to modify netfilter rule sets."
}