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') •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48975 – gpiolib: fix memory leak in gpiochip_setup_dev()
https://notcve.org/view.php?id=CVE-2022-48975
In the Linux kernel, the following vulnerability has been resolved: gpiolib: fix memory leak in gpiochip_setup_dev() Here is a backtrace report about memory leak detected in gpiochip_setup_dev(): unreferenced object 0xffff88810b406400 (size 512): comm "python3", pid 1682, jiffies 4295346908 (age 24.090s) backtrace: kmalloc_trace device_add device_private_init at drivers/base/core.c:3361 (inlined by) device_add at drivers/base/core.c:3411 cdev_device_add gpiolib_cdev_register gpiochip_setup_dev gpiochip_add_data_with_key gcdev_register() & gcdev_unregister() would call device_add() & device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to register/unregister device. However, if device_add() succeeds, some resource (like struct device_private allocated by device_private_init()) is not released by device_del(). Therefore, after device_add() succeeds by gcdev_register(), it needs to call put_device() to release resource in the error handle path. Here we move forward the register of release function, and let it release every piece of resource by put_device() instead of kfree(). While at it, fix another subtle issue, i.e. when gc->ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZERO_PTR pointer, which is not NULL. It's not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev->descs variable. • https://git.kernel.org/stable/c/159f3cd92f17c61a4e2a47456de5865b114ef88e https://git.kernel.org/stable/c/6daaa84b621485fe28c401be18debf92ae8ef04a https://git.kernel.org/stable/c/371363716398ed718e389bea8c5e9843a79dde4e https://git.kernel.org/stable/c/ec851b23084b3a0af8bf0f5e51d33a8d678bdc49 •