CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48980 – net: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing()
https://notcve.org/view.php?id=CVE-2022-48980
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). • https://git.kernel.org/stable/c/38fbe91f2287c696f290d9115901aa435f7166a8 https://git.kernel.org/stable/c/5e88c6f4aaa70c542e59e5a9d2244bcc99cd245d https://git.kernel.org/stable/c/147f3e3d84054117ae6b9bf317ec4fda9f991192 https://git.kernel.org/stable/c/f8bac7f9fdb0017b32157957ffffd490f95faa07 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48979 – drm/amd/display: fix array index out of bound error in DCN32 DML
https://notcve.org/view.php?id=CVE-2022-48979
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix array index out of bound error in DCN32 DML [Why&How] LinkCapacitySupport array is indexed with the number of voltage states and not the number of max DPPs. Fix the error by changing the array declaration to use the correct (larger) array size of total number of voltage states. • https://git.kernel.org/stable/c/3d8a298b2e83b98042e6ec726e934f535b23e6aa https://git.kernel.org/stable/c/aeffc8fb2174f017a10df114bc312f899904dc68 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48978 – HID: core: fix shift-out-of-bounds in hid_report_raw_event
https://notcve.org/view.php?id=CVE-2022-48978
In the Linux kernel, the following vulnerability has been resolved: HID: core: fix shift-out-of-bounds in hid_report_raw_event Syzbot reported shift-out-of-bounds in hid_report_raw_event. microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) > 32! (swapper/0) ====================================================================== UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20 shift exponent 127 is too large for 32-bit type 'int' CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322 snto32 drivers/hid/hid-core.c:1323 [inline] hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline] hid_process_report drivers/hid/hid-core.c:1665 [inline] hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998 hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066 hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284 __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671 dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988 call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [inline] __run_timers+0x76a/0x980 kernel/time/timer.c:1790 run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803 __do_softirq+0x277/0x75b kernel/softirq.c:571 __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107 ====================================================================== If the size of the integer (unsigned n) is bigger than 32 in snto32(), shift exponent will be too large for 32-bit type 'int', resulting in a shift-out-of-bounds bug. Fix this by adding a check on the size of the integer (unsigned n) in snto32(). To add support for n greater than 32 bits, set n to 32, if n is greater than 32. • https://git.kernel.org/stable/c/dde5845a529ff753364a6d1aea61180946270bfa https://git.kernel.org/stable/c/151493fe5a6ed1a88decc929a7368a3f2a246914 https://git.kernel.org/stable/c/809783f8b4b600c7fb3bccb10fefef822601ea3b https://git.kernel.org/stable/c/8e14f20e12224ee2429f75a5c9418a700e26a8d3 https://git.kernel.org/stable/c/db1ed1b3fb4ec0d19080a102956255769bc45c79 https://git.kernel.org/stable/c/bc03f809da78fc79e4aee132d4e5c6a2b3aeec73 https://git.kernel.org/stable/c/f755d11c55b29049b77da5cd9ab2faae96eb33c3 https://git.kernel.org/stable/c/2b3b4d7aadaa1b6b58d0f34823bf86cfe •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48977 – can: af_can: fix NULL pointer dereference in can_rcv_filter
https://notcve.org/view.php?id=CVE-2022-48977
In the Linux kernel, the following vulnerability has been resolved: can: af_can: fix NULL pointer dereference in can_rcv_filter Analogue to commit 8aa59e355949 ("can: af_can: fix NULL pointer dereference in can_rx_register()") we need to check for a missing initialization of ml_priv in the receive path of CAN frames. Since commit 4e096a18867a ("net: introduce CAN specific pointer in the struct net_device") the check for dev->type to be ARPHRD_CAN is not sufficient anymore since bonding or tun netdevices claim to be CAN devices but do not initialize ml_priv accordingly. • https://git.kernel.org/stable/c/4ac1feff6ea6495cbfd336f4438a6c6d140544a6 https://git.kernel.org/stable/c/1a5751d58b14195f763b8c1d9ef33fb8a93e95e7 https://git.kernel.org/stable/c/4e096a18867a5a989b510f6999d9c6b6622e8f7b https://git.kernel.org/stable/c/96340078d50a54f6a1252c62596bc44321c8bff9 https://git.kernel.org/stable/c/3982652957e8d79ac32efcb725450580650a8644 https://git.kernel.org/stable/c/c42221efb1159d6a3c89e96685ee38acdce86b6f https://git.kernel.org/stable/c/c142cba37de29f740a3852f01f59876af8ae462a https://git.kernel.org/stable/c/fcc63f2f7ee3038d53216edd0d8291e57 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48976 – netfilter: flowtable_offload: fix using __this_cpu_add in preemptible
https://notcve.org/view.php?id=CVE-2022-48976
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable_offload: fix using __this_cpu_add in preemptible flow_offload_queue_work() can be called in workqueue without bh disabled, like the call trace showed in my act_ct testing, calling NF_FLOW_TABLE_STAT_INC() there would cause a call trace: BUG: using __this_cpu_add() in preemptible [00000000] code: kworker/u4:0/138560 caller is flow_offload_queue_work+0xec/0x1b0 [nf_flow_table] Workqueue: act_ct_workqueue tcf_ct_flow_table_cleanup_work [act_ct] Call Trace: <TASK> dump_stack_lvl+0x33/0x46 check_preemption_disabled+0xc3/0xf0 flow_offload_queue_work+0xec/0x1b0 [nf_flow_table] nf_flow_table_iterate+0x138/0x170 [nf_flow_table] nf_flow_table_free+0x140/0x1a0 [nf_flow_table] tcf_ct_flow_table_cleanup_work+0x2f/0x2b0 [act_ct] process_one_work+0x6a3/0x1030 worker_thread+0x8a/0xdf0 This patch fixes it by using NF_FLOW_TABLE_STAT_INC_ATOMIC() instead in flow_offload_queue_work(). Note that for FLOW_CLS_REPLACE branch in flow_offload_queue_work(), it may not be called in preemptible path, but it's good to use NF_FLOW_TABLE_STAT_INC_ATOMIC() for all cases in flow_offload_queue_work(). • https://git.kernel.org/stable/c/b038177636f83bbf87c2b238706474145dd2cd04 https://git.kernel.org/stable/c/5345d78ae64d5a760c211cd2da995dc71c5b29e4 https://git.kernel.org/stable/c/a220a11fda012fba506b35929672374c2723ae6d https://git.kernel.org/stable/c/a81047154e7ce4eb8769d5d21adcbc9693542a79 https://access.redhat.com/security/cve/CVE-2022-48976 https://bugzilla.redhat.com/show_bug.cgi?id=2320792 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •