CVE-2022-48980
Severity CVSS v4.0:
Pending analysis
Type:
CWE-787
Out-of-bounds Write
Publication date:
21/10/2024
Last modified:
25/10/2024
Description
In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
net: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing()<br />
<br />
The SJA1105 family has 45 L2 policing table entries<br />
(SJA1105_MAX_L2_POLICING_COUNT) and SJA1110 has 110<br />
(SJA1110_MAX_L2_POLICING_COUNT). Keeping the table structure but<br />
accounting for the difference in port count (5 in SJA1105 vs 10 in<br />
SJA1110) does not fully explain the difference. Rather, the SJA1110 also<br />
has L2 ingress policers for multicast traffic. If a packet is classified<br />
as multicast, it will be processed by the policer index 99 + SRCPORT.<br />
<br />
The sja1105_init_l2_policing() function initializes all L2 policers such<br />
that they don&#39;t interfere with normal packet reception by default. To have<br />
a common code between SJA1105 and SJA1110, the index of the multicast<br />
policer for the port is calculated because it&#39;s an index that is out of<br />
bounds for SJA1105 but in bounds for SJA1110, and a bounds check is<br />
performed.<br />
<br />
The code fails to do the proper thing when determining what to do with the<br />
multicast policer of port 0 on SJA1105 (ds->num_ports = 5). The "mcast"<br />
index will be equal to 45, which is also equal to<br />
table->ops->max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). So it passes<br />
through the check. But at the same time, SJA1105 doesn&#39;t have multicast<br />
policers. So the code programs the SHARINDX field of an out-of-bounds<br />
element in the L2 Policing table of the static config.<br />
<br />
The comparison between index 45 and 45 entries should have determined the<br />
code to not access this policer index on SJA1105, since its memory wasn&#39;t<br />
even allocated.<br />
<br />
With enough bad luck, the out-of-bounds write could even overwrite other<br />
valid kernel data, but in this case, the issue was detected using KASAN.<br />
<br />
Kernel log:<br />
<br />
sja1105 spi5.0: Probed switch chip: SJA1105Q<br />
==================================================================<br />
BUG: KASAN: slab-out-of-bounds in sja1105_setup+0x1cbc/0x2340<br />
Write of size 8 at addr ffffff880bd57708 by task kworker/u8:0/8<br />
...<br />
Workqueue: events_unbound deferred_probe_work_func<br />
Call trace:<br />
...<br />
sja1105_setup+0x1cbc/0x2340<br />
dsa_register_switch+0x1284/0x18d0<br />
sja1105_probe+0x748/0x840<br />
...<br />
Allocated by task 8:<br />
...<br />
sja1105_setup+0x1bcc/0x2340<br />
dsa_register_switch+0x1284/0x18d0<br />
sja1105_probe+0x748/0x840<br />
...
Impact
Base Score 3.x
7.80
Severity 3.x
HIGH
Vulnerable products and versions
| CPE | From | Up to |
|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | 5.14 (including) | 5.15.83 (excluding) |
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | 5.16 (including) | 6.0.13 (excluding) |
| cpe:2.3:o:linux:linux_kernel:6.1:rc1:*:*:*:*:*:* | ||
| cpe:2.3:o:linux:linux_kernel:6.1:rc2:*:*:*:*:*:* | ||
| cpe:2.3:o:linux:linux_kernel:6.1:rc3:*:*:*:*:*:* | ||
| cpe:2.3:o:linux:linux_kernel:6.1:rc4:*:*:*:*:*:* | ||
| cpe:2.3:o:linux:linux_kernel:6.1:rc5:*:*:*:*:*:* | ||
| cpe:2.3:o:linux:linux_kernel:6.1:rc6:*:*:*:*:*:* | ||
| cpe:2.3:o:linux:linux_kernel:6.1:rc7:*:*:*:*:*:* | ||
| cpe:2.3:o:linux:linux_kernel:6.1:rc8:*:*:*:*:*:* |
To consult the complete list of CPE names with products and versions, see this page



