In the Linux kernel, the following vulnerability has been resolved:
net: dsa: bcm_sf2: bound the CFP rule dump by the caller's buffer size
bcm_sf2_cfp_rule_get_all() walks the whole cfp.unique bitmap into
rule_locs[] without consulting nfc->rule_cnt, which is how many 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 CFP 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.
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 trigger is the local SIOCETHTOOL ioctl with ETHTOOL_GRXCLSRLALL on a bcm_sf2 DSA user port. The path is ethtool_get_rxnfc() -> dsa_user_get_rxnfc() -> bcm_sf2_get_rxnfc() -> bcm_sf2_cfp_rule_get_all(). The bad rule_cnt comes from userspace, and no packet from a remote peer is involved.
AC:H - The overflow needs CFP rules installed beyond the default at bit 0 of cfp.unique, since the walk starts at index 1. Installing them via ETHTOOL_SRXCLSRLINS needs CAP_NET_ADMIN over the switch's netns, so the unprivileged attacker cannot create the rule state. Once rules exist, the bug fires every time.
PR:L - ETHTOOL_GRXCLSRLALL is on ethtool's no-capability list in net/ethtool/ioctl.c, so any unprivileged local user who can open a socket in the netns holding the DSA port can send the dump request.
UI:N - The attacker issues the ioctl themselves and picks rule_cnt. No other user has to act.
S:U - Both the memory corruption and the leak stay inside the kernel's own security authority, with no VM or IOMMU boundary crossed.
C:H - After the walk, nfc->rule_cnt holds the real rule count, which can be larger than the buffer. ethtool_rxnfc_copy_to_user() then copies rule_cnt*4 bytes from the undersized kcalloc buffer to userspace. That leaks up to about 1 KB of adjacent heap from a slab cache the attacker chooses.
I:H - bcm_sf2_cfp_rule_get_all() writes u32 rule indices past a kcalloc(rule_cnt) buffer sized by the user. This is a heap out-of-bounds write into neighbouring objects in a slab cache the attacker picks, and it can corrupt kernel data structures.
A:H - With rule_cnt=0 the rule_locs buffer stays NULL, so the walk writes through a NULL pointer and the kernel oopses. Any user can repeat this at will once rules are installed. Heap corruption from the out-of-bounds write can also crash the system.
| 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 trigger is the local SIOCETHTOOL ioctl with ETHTOOL_GRXCLSRLALL on a bcm_sf2 DSA user port. The path is ethtool_get_rxnfc() -> dsa_user_get_rxnfc() -> bcm_sf2_get_rxnfc() -> bcm_sf2_cfp_rule_get_all(). The bad rule_cnt comes from userspace, and no packet from a remote peer is involved.
AC:H - The overflow needs CFP rules installed beyond the default at bit 0 of cfp.unique, since the walk starts at index 1. Installing them via ETHTOOL_SRXCLSRLINS needs CAP_NET_ADMIN over the switch's netns, so the unprivileged attacker cannot create the rule state. Once rules exist, the bug fires every time.
PR:L - ETHTOOL_GRXCLSRLALL is on ethtool's no-capability list in net/ethtool/ioctl.c, so any unprivileged local user who can open a socket in the netns holding the DSA port can send the dump request.
UI:N - The attacker issues the ioctl themselves and picks rule_cnt. No other user has to act.
S:U - Both the memory corruption and the leak stay inside the kernel's own security authority, with no VM or IOMMU boundary crossed.
C:H - After the walk, nfc->rule_cnt holds the real rule count, which can be larger than the buffer. ethtool_rxnfc_copy_to_user() then copies rule_cnt*4 bytes from the undersized kcalloc buffer to userspace. That leaks up to about 1 KB of adjacent heap from a slab cache the attacker chooses.
I:H - bcm_sf2_cfp_rule_get_all() writes u32 rule indices past a kcalloc(rule_cnt) buffer sized by the user. This is a heap out-of-bounds write into neighbouring objects in a slab cache the attacker picks, and it can corrupt kernel data structures.
A:H - With rule_cnt=0 the rule_locs buffer stays NULL, so the walk writes through a NULL pointer and the kernel oopses. Any user can repeat this at will once rules are installed. Heap corruption from the out-of-bounds write can also crash the system.
CVSS 3.1