| From bippy-5f407fcff5a0 Mon Sep 17 00:00:00 2001 |
| From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| To: <linux-cve-announce@vger.kernel.org> |
| Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org> |
| Subject: CVE-2022-48980: net: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing() |
| |
| Description |
| =========== |
| |
| 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 |
| ... |
| |
| The Linux kernel CVE team has assigned CVE-2022-48980 to this issue. |
| |
| |
| Affected and fixed versions |
| =========================== |
| |
| Issue introduced in 5.14 with commit 38fbe91f2287c696f290d9115901aa435f7166a8 and fixed in 5.15.83 with commit 5e88c6f4aaa70c542e59e5a9d2244bcc99cd245d |
| Issue introduced in 5.14 with commit 38fbe91f2287c696f290d9115901aa435f7166a8 and fixed in 6.0.13 with commit 147f3e3d84054117ae6b9bf317ec4fda9f991192 |
| Issue introduced in 5.14 with commit 38fbe91f2287c696f290d9115901aa435f7166a8 and fixed in 6.1 with commit f8bac7f9fdb0017b32157957ffffd490f95faa07 |
| |
| Please see https://www.kernel.org for a full list of currently supported |
| kernel versions by the kernel community. |
| |
| Unaffected versions might change over time as fixes are backported to |
| older supported kernel versions. The official CVE entry at |
| https://cve.org/CVERecord/?id=CVE-2022-48980 |
| will be updated if fixes are backported, please check that for the most |
| up to date information about this issue. |
| |
| |
| Affected files |
| ============== |
| |
| The file(s) affected by this issue are: |
| drivers/net/dsa/sja1105/sja1105_main.c |
| |
| |
| Mitigation |
| ========== |
| |
| The Linux kernel CVE team recommends that you update to the latest |
| stable kernel version for this, and many other bugfixes. Individual |
| changes are never tested alone, but rather are part of a larger kernel |
| release. Cherry-picking individual commits is not recommended or |
| supported by the Linux kernel community at all. If however, updating to |
| the latest release is impossible, the individual changes to resolve this |
| issue can be found at these commits: |
| https://git.kernel.org/stable/c/5e88c6f4aaa70c542e59e5a9d2244bcc99cd245d |
| https://git.kernel.org/stable/c/147f3e3d84054117ae6b9bf317ec4fda9f991192 |
| https://git.kernel.org/stable/c/f8bac7f9fdb0017b32157957ffffd490f95faa07 |
