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.
CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7
AV:L - The overflow is reached only through the local SIOCETHTOOL ioctl: dev_ethtool() -> ethtool_get_rxnfc() -> dsa_user_get_rxnfc() -> mv88e6xxx_get_rxnfc(ETHTOOL_GRXCLSRLALL). The bad input is the rule_cnt field of the ethtool_rxnfc struct the user passes in. No network packet reaches this path.
AC:H - The OOB write only happens if policy rules already exist in chip->policies for that DSA port. Those are installed by an admin via ETHTOOL_SRXCLSRLINS, which needs CAP_NET_ADMIN over the hardware port. The attacker can't create that state. Once rules exist, a small rule_cnt triggers it deterministically.
PR:L - dev_ethtool() lists ETHTOOL_GRXCLSRLALL among the commands exempt from the ns_capable(CAP_NET_ADMIN) check. Any unprivileged local user who can see the mv88e6xxx user port in their netns can issue the ioctl.
UI:N - The attacker makes the ioctl call and picks rule_cnt themselves. No other user has to do anything.
S:U - The corruption hits the kernel heap in the same kernel that runs the attacker's ioctl. No VM, IOMMU or other authority boundary is crossed.
C:H - ethtool_get_rxnfc() sizes rule_buf with kcalloc(rule_cnt, 4) from the user's value. The driver then overwrites rxnfc->rule_cnt with the real rule count, so ethtool_rxnfc_copy_to_user() copies that many u32s from the undersized buffer, reading past the slab object into userspace. The same heap corruption can also be groomed to leak more.
I:H - mv88e6xxx_get_rxnfc() writes rule_locs[rxnfc->rule_cnt++] = id for every rule on the port with no bound, so u32 IDs go past a kmalloc object whose size and cache the attacker chose via rule_cnt. That heap OOB write can corrupt neighbouring objects.
A:H - With rule_cnt=0, ethtool_get_rxnfc() passes a NULL rule_buf and the IDR walk writes through it, oopsing the kernel on demand. Larger overflows corrupt slab memory and can panic the system. Either can be repeated.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
High |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The overflow is reached only through the local SIOCETHTOOL ioctl: dev_ethtool() -> ethtool_get_rxnfc() -> dsa_user_get_rxnfc() -> mv88e6xxx_get_rxnfc(ETHTOOL_GRXCLSRLALL). The bad input is the rule_cnt field of the ethtool_rxnfc struct the user passes in. No network packet reaches this path.
AC:H - The OOB write only happens if policy rules already exist in chip->policies for that DSA port. Those are installed by an admin via ETHTOOL_SRXCLSRLINS, which needs CAP_NET_ADMIN over the hardware port. The attacker can't create that state. Once rules exist, a small rule_cnt triggers it deterministically.
PR:L - dev_ethtool() lists ETHTOOL_GRXCLSRLALL among the commands exempt from the ns_capable(CAP_NET_ADMIN) check. Any unprivileged local user who can see the mv88e6xxx user port in their netns can issue the ioctl.
UI:N - The attacker makes the ioctl call and picks rule_cnt themselves. No other user has to do anything.
S:U - The corruption hits the kernel heap in the same kernel that runs the attacker's ioctl. No VM, IOMMU or other authority boundary is crossed.
C:H - ethtool_get_rxnfc() sizes rule_buf with kcalloc(rule_cnt, 4) from the user's value. The driver then overwrites rxnfc->rule_cnt with the real rule count, so ethtool_rxnfc_copy_to_user() copies that many u32s from the undersized buffer, reading past the slab object into userspace. The same heap corruption can also be groomed to leak more.
I:H - mv88e6xxx_get_rxnfc() writes rule_locs[rxnfc->rule_cnt++] = id for every rule on the port with no bound, so u32 IDs go past a kmalloc object whose size and cache the attacker chose via rule_cnt. That heap OOB write can corrupt neighbouring objects.
A:H - With rule_cnt=0, ethtool_get_rxnfc() passes a NULL rule_buf and the IDR walk writes through it, oopsing the kernel on demand. Larger overflows corrupt slab memory and can panic the system. Either can be repeated.
CVSS 3.1