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&amp;#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&amp;#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-&gt;num_ports = 5). The "mcast"<br /> index will be equal to 45, which is also equal to<br /> table-&gt;ops-&gt;max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). So it passes<br /> through the check. But at the same time, SJA1105 doesn&amp;#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&amp;#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 /> ...

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:*:*:*:*:*:*