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-48969 – xen-netfront: Fix NULL sring after live migration
https://notcve.org/view.php?id=CVE-2022-48969
In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Fix NULL sring after live migration A NAPI is setup for each network sring to poll data to kernel The sring with source host is destroyed before live migration and new sring with target host is setup after live migration. The NAPI for the old sring is not deleted until setup new sring with target host after migration. With busy_poll/busy_read enabled, the NAPI can be polled before got deleted when resume VM. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Call Trace: finish_task_switch+0x71/0x230 timerqueue_del+0x1d/0x40 hrtimer_try_to_cancel+0xb5/0x110 xennet_alloc_rx_buffers+0x2a0/0x2a0 napi_busy_loop+0xdb/0x270 sock_poll+0x87/0x90 do_sys_poll+0x26f/0x580 tracing_map_insert+0x1d4/0x2f0 event_hist_trigger+0x14a/0x260 finish_task_switch+0x71/0x230 __schedule+0x256/0x890 recalc_sigpending+0x1b/0x50 xen_sched_clock+0x15/0x20 __rb_reserve_next+0x12d/0x140 ring_buffer_lock_reserve+0x123/0x3d0 event_triggers_call+0x87/0xb0 trace_event_buffer_commit+0x1c4/0x210 xen_clocksource_get_cycles+0x15/0x20 ktime_get_ts64+0x51/0xf0 SyS_ppoll+0x160/0x1a0 SyS_ppoll+0x160/0x1a0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ end trace f8601785b354351c ]--- xen frontend should remove the NAPIs for the old srings before live migration as the bond srings are destroyed There is a tiny window between the srings are set to NULL and the NAPIs are disabled, It is safe as the NAPI threads are still frozen at that time • https://git.kernel.org/stable/c/4ec2411980d0fd2995e8dea8a06fe57aa47523cb https://git.kernel.org/stable/c/99859947517e446058ad7243ee81d2f9801fa3dd https://git.kernel.org/stable/c/ed773dd798bf720756d20021b8d8a4a3d7184bda https://git.kernel.org/stable/c/e6860c889f4ad50b6ab696f5ea154295d72cf27a https://git.kernel.org/stable/c/e6e897d4fe2f89c0bd94600a40bedf5e6e75e050 https://git.kernel.org/stable/c/f2dd60fd3fe98bd36a91b0c6e10bfe9d66258f84 https://git.kernel.org/stable/c/d50b7914fae04d840ce36491d22133070b18cca9 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48958 – ethernet: aeroflex: fix potential skb leak in greth_init_rings()
https://notcve.org/view.php?id=CVE-2022-48958
In the Linux kernel, the following vulnerability has been resolved: ethernet: aeroflex: fix potential skb leak in greth_init_rings() The greth_init_rings() function won't free the newly allocated skb when dma_mapping_error() returns error, so add dev_kfree_skb() to fix it. Compile tested only. • https://git.kernel.org/stable/c/d4c41139df6e74c6fff0cbac43e51cab782133be https://git.kernel.org/stable/c/223654e2e2c8d05347cd8e300f8d1ec6023103dd https://git.kernel.org/stable/c/cb1e293f858e5e1152b8791047ed4bdaaf392189 https://git.kernel.org/stable/c/bfaa8f6c5b84b295dd73b0138b57c5555ca12b1c https://git.kernel.org/stable/c/99669d94ce145389f1d6f197e6e18ed50d43fb76 https://git.kernel.org/stable/c/87277bdf2c370ab2d07cfe77dfa9b37f82bbe1e5 https://git.kernel.org/stable/c/c7adcbd0fd3fde1b19150c3e955fb4a30c5bd9b7 https://git.kernel.org/stable/c/dd62867a6383f78f75f07039394aac259 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48953 – rtc: cmos: Fix event handler registration ordering issue
https://notcve.org/view.php?id=CVE-2022-48953
In the Linux kernel, the following vulnerability has been resolved: rtc: cmos: Fix event handler registration ordering issue Because acpi_install_fixed_event_handler() enables the event automatically on success, it is incorrect to call it before the handler routine passed to it is ready to handle events. Unfortunately, the rtc-cmos driver does exactly the incorrect thing by calling cmos_wake_setup(), which passes rtc_handler() to acpi_install_fixed_event_handler(), before cmos_do_probe(), because rtc_handler() uses dev_get_drvdata() to get to the cmos object pointer and the driver data pointer is only populated in cmos_do_probe(). This leads to a NULL pointer dereference in rtc_handler() on boot if the RTC fixed event happens to be active at the init time. To address this issue, change the initialization ordering of the driver so that cmos_wake_setup() is always called after a successful cmos_do_probe() call. While at it, change cmos_pnp_probe() to call cmos_do_probe() after the initial if () statement used for computing the IRQ argument to be passed to cmos_do_probe() which is cleaner than calling it in each branch of that if () (local variable "irq" can be of type int, because it is passed to that function as an argument of type int). Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number of systems, because previously it only affected systems with ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that commit. • https://git.kernel.org/stable/c/a474aaedac99ba86e28ef6c912a7647c482db6dd https://git.kernel.org/stable/c/0bcfccb48696aba475f046c2021f0733659ce0ef https://git.kernel.org/stable/c/60c6e563a843032cf6ff84b2fb732cd8754fc10d https://git.kernel.org/stable/c/1ba745fce13d19775100eece30b0bfb8b8b10ea6 https://git.kernel.org/stable/c/4919d3eb2ec0ee364f7e3cf2d99646c1b224fae8 •
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 •