CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48990 – drm/amdgpu: fix use-after-free during gpu recovery
https://notcve.org/view.php?id=CVE-2022-48990
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix use-after-free during gpu recovery [Why] [ 754.862560] refcount_t: underflow; use-after-free. [ 754.862898] Call Trace: [ 754.862903] <TASK> [ 754.862913] amdgpu_job_free_cb+0xc2/0xe1 [amdgpu] [ 754.863543] drm_sched_main.cold+0x34/0x39 [amd_sched] [How] The fw_fence may be not init, check whether dma_fence_init is performed before job free • https://git.kernel.org/stable/c/d2a89cd942edd50c1e652004fd64019be78b0a96 https://git.kernel.org/stable/c/3cb93f390453cde4d6afda1587aaa00e75e09617 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48982 – Bluetooth: Fix crash when replugging CSR fake controllers
https://notcve.org/view.php?id=CVE-2022-48982
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix crash when replugging CSR fake controllers It seems fake CSR 5.0 clones can cause the suspend notifier to be registered twice causing the following kernel panic: [ 71.986122] Call Trace: [ 71.986124] <TASK> [ 71.986125] blocking_notifier_chain_register+0x33/0x60 [ 71.986130] hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da] [ 71.986154] btusb_probe+0x979/0xd85 [btusb e1e0605a4f4c01984a4b9c8ac58c3666ae287477] [ 71.986159] ? __pm_runtime_set_status+0x1a9/0x300 [ 71.986162] ? ktime_get_mono_fast_ns+0x3e/0x90 [ 71.986167] usb_probe_interface+0xe3/0x2b0 [ 71.986171] really_probe+0xdb/0x380 [ 71.986174] ? pm_runtime_barrier+0x54/0x90 [ 71.986177] __driver_probe_device+0x78/0x170 [ 71.986180] driver_probe_device+0x1f/0x90 [ 71.986183] __device_attach_driver+0x89/0x110 [ 71.986186] ? driver_allows_async_probing+0x70/0x70 [ 71.986189] bus_for_each_drv+0x8c/0xe0 [ 71.986192] __device_attach+0xb2/0x1e0 [ 71.986195] bus_probe_device+0x92/0xb0 [ 71.986198] device_add+0x422/0x9a0 [ 71.986201] ? • https://git.kernel.org/stable/c/549b46f8130effccf168293270bb3b1d5da529cc https://git.kernel.org/stable/c/a49894a5ac3656f1a4f0f6b110460060e8026bf8 https://git.kernel.org/stable/c/dc8fa6570deadb70c3fb74d7cd8ce38849feaed0 https://git.kernel.org/stable/c/b5ca338751ad4783ec8d37b5d99c3e37b7813e59 •
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: 8EXPL: 0CVE-2022-48951 – ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx()
https://notcve.org/view.php?id=CVE-2022-48951
In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx() The bounds checks in snd_soc_put_volsw_sx() are only being applied to the first channel, meaning it is possible to write out of bounds values to the second channel in stereo controls. Add appropriate checks. • https://git.kernel.org/stable/c/56288987843c3cb343e81e5fa51549cbaf541bd0 https://git.kernel.org/stable/c/cf1c225f1927891ae388562b78ced7840c3723b9 https://git.kernel.org/stable/c/18a168d85eadcfd45f015b5ecd2a97801b959e43 https://git.kernel.org/stable/c/9796d07c753164b7e6b0d7ef23fb4482840a9ef8 https://git.kernel.org/stable/c/50b5f6d4d9d2d69a7498c44fd8b26e13d73d3d98 https://git.kernel.org/stable/c/cf611d786796ec33da09d8c83d7d7f4e557b27de https://git.kernel.org/stable/c/1798b62d642e7b3d4ea3403914c3caf4e438465d https://git.kernel.org/stable/c/97eea946b93961fffd29448dcda7398d0 •