Description

In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: bound the policy rule dump by the caller's buffer size mv88e6xxx_get_rxnfc() uses rxnfc->rule_cnt as the write index while dumping the policy IDR, clobbering the input value before it has been looked at. That input is the number of entries the caller had room for. ETHTOOL_GRXCLSRLALL requires no CAP_NET_ADMIN and the ioctl sizes the buffer from the rule_cnt userspace passes in, so once an admin has installed policy rules any user can ask for fewer slots than there are rules and run off the end of the allocation. A rule_cnt of 0 leaves the buffer pointer NULL and the walk dereferences it. Count into a local so the caller's limit survives the walk, and stop with -EMSGSIZE once it is reached.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.0",
  "pubDate": "2026-09-25T11:17:31.340Z",
  "pubdate": "2026-09-25T11:17:31.340Z",
  "executiveSummary": "The mv88e6xxx Linux kernel driver suffers from an out-of-bounds memory access vulnerability during the retrieval of RX network flow classification (rxnfc) rules. The vulnerability arises due to improper boundary checking when interacting with userspace buffers provided via the ETHTOOL_GRXCLSRLALL ioctl. An unprivileged attacker can trigger a kernel memory corruption or a system crash by providing an undersized buffer, which causes the driver to write beyond the allocated memory boundaries. This issue stems from the clobbering of the rule counter, which dictates the safe write limit for the provided buffer. Successful exploitation allows for localized memory corruption, which could potentially lead to a denial-of-service (DoS) condition or privilege escalation depending on the environment. The vulnerability is exploitable by any user who can interact with the netlink interface, as the ETHTOOL_GRXCLSRLALL operation does not require CAP_NET_ADMIN privileges. Remediation requires patching the driver to properly track the caller's buffer capacity using a local index rather than overwriting it with the IDR traversal state.",
  "technicalDetails": "The vulnerability resides within the mv88e6xxx_get_rxnfc function of the Linux kernel's DSA (Distributed Switch Architecture) subsystem. The core issue is an input validation failure regarding the rxnfc->rule_cnt parameter during an IDR (Integer ID Management) table dump.\nWhen a user invokes ETHTOOL_GRXCLSRLALL to retrieve installed flow classification rules, the driver performs a walk of the internal IDR policy structure. The input parameter rule_cnt represents the maximum number of entries the userspace buffer is sized to hold. However, the driver incorrectly uses the same rule_cnt field as the current write index for populating the buffer. By overwriting the input limit with the progress counter, the driver loses track of the buffer's allocated capacity.\nThe attack flow follows these steps: 1) The attacker installs flow rules (if an admin has already populated the table). 2) The attacker calls ETHTOOL_GRXCLSRLALL with a small or zero value in rule_cnt. 3) If rule_cnt is set to zero, the buffer pointer remains NULL; the subsequent IDR walk attempts to dereference this pointer, leading to a kernel panic (null pointer dereference). 4) If rule_cnt is non-zero but smaller than the total number of rules, the driver continues to write rules to the user-provided memory area beyond the length allocated for the operation. This leads to a heap-based buffer overflow, as the code continues to copy rule data until the internal IDR walk completes, regardless of the initial constraint defined by the user.\nBecause ETHTOOL_GRXCLSRLALL is exposed to all users, no administrative privileges are required to initiate the attack. The lack of bounds checking on the kernel-side copy operation means that any attempt to retrieve these rules with a purposefully malformed request can result in arbitrary memory corruption in the context of the kernel stack or heap, depending on how the buffer is managed. The root cause is the conflation of the input constraint (the caller's limit) and the iteration progress variable, allowing the loop logic to exceed the memory safe-zone boundaries."
}