CVE-2022-48980: net: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing()
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing()
The SJA1105 family has 45 L2 policing table entries
(SJA1105_MAX_L2_POLICING_COUNT) and SJA1110 has 110
(SJA1110_MAX_L2_POLICING_COUNT). Keeping the table structure but
accounting for the difference in port count (5 in SJA1105 vs 10 in
SJA1110) does not fully explain the difference. Rather, the SJA1110 also
has L2 ingress policers for multicast traffic. If a packet is classified
as multicast, it will be processed by the policer index 99 + SRCPORT.
The sja1105_init_l2_policing() function initializes all L2 policers such
that they don't interfere with normal packet reception by default. To have
a common code between SJA1105 and SJA1110, the index of the multicast
policer for the port is calculated because it's an index that is out of
bounds for SJA1105 but in bounds for SJA1110, and a bounds check is
performed.
The code fails to do the proper thing when determining what to do with the
multicast policer of port 0 on SJA1105 (ds->num_ports = 5). The "mcast"
index will be equal to 45, which is also equal to
table->ops->max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). So it passes
through the check. But at the same time, SJA1105 doesn't have multicast
policers. So the code programs the SHARINDX field of an out-of-bounds
element in the L2 Policing table of the static config.
The comparison between index 45 and 45 entries should have determined the
code to not access this policer index on SJA1105, since its memory wasn't
even allocated.
With enough bad luck, the out-of-bounds write could even overwrite other
valid kernel data, but in this case, the issue was detected using KASAN.
Kernel log:
sja1105 spi5.0: Probed switch chip: SJA1105Q
==================================================================
BUG: KASAN: slab-out-of-bounds in sja1105_setup+0x1cbc/0x2340
Write of size 8 at addr ffffff880bd57708 by task kworker/u8:0/8
...
Workqueue: events_unbound deferred_probe_work_func
Call trace:
...
sja1105_setup+0x1cbc/0x2340
dsa_register_switch+0x1284/0x18d0
sja1105_probe+0x748/0x840
...
Allocated by task 8:
...
sja1105_setup+0x1bcc/0x2340
dsa_register_switch+0x1284/0x18d0
sja1105_probe+0x748/0x840
...
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel driver memory-corruption bug in the SJA1105 DSA Ethernet switch support. On affected systems, initialization can write past an allocated table. The available sources show it was found with KASAN and fixed in stable kernel commits, but do not show active exploitation.
Executive priority
Treat as a targeted infrastructure maintenance issue, not a broad internet emergency. Prioritize affected embedded networking products and appliances, especially where kernel updates are centrally managed or delayed.
Technical view
sja1105_init_l2_policing() calculated multicast policer index 45 for SJA1105 port 0 and used an insufficient bounds check. Because SJA1105 has 45 L2 policing entries and no multicast policers, index 45 is out of bounds, causing a slab out-of-bounds write during switch setup/probe.
Likely exposure
Exposure appears limited to Linux systems using the sja1105 DSA switch driver and affected SJA1105-family hardware paths. Generic Linux servers without this driver or hardware are unlikely to be exposed based on the provided sources.
Exploitation context
The source bundle does not cite KEV listing, public exploitation, or a weaponized attack path. The evidence describes detection through KASAN during kernel probe/setup, with possible overwrite of other kernel data under unlucky memory layout conditions.
Researcher notes
The key condition is the off-by-one bounds decision where index 45 equals max_entry_count for SJA1105. Sources do not provide CVSS, CWE, exploit prerequisites, or external attack reachability, so exposure assessment depends on local hardware and kernel build context.
Mitigation direction
Update to a Linux stable kernel containing the referenced fixes.
Check your distribution or device vendor advisory for backported fixes.
Prioritize embedded, networking, and appliance builds using SJA1105 hardware.
If patching is delayed, assess whether the affected driver is needed.
Validation and detection
Inventory kernels and device trees for SJA1105 or sja1105 driver usage.
Compare deployed kernel versions against vendor-fixed builds or stable commits.
Review boot and kernel logs for KASAN or sja1105 setup errors.
Confirm patched systems include the referenced stable fix lineage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2022-48980 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.