Page 13 of 3043 results (0.005 seconds)

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

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: 0

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 •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: perf: Fix perf_pending_task() UaF Per syzbot it is possible for perf_pending_task() to run after the event is free()'d. There are two related but distinct cases: - the task_work was already queued before destroying the event; - destroying the event itself queues the task_work. The first cannot be solved using task_work_cancel() since perf_release() itself might be called from a task_work (____fput), which means the current->task_works list is already empty and task_work_cancel() won't be able to find the perf_pending_task() entry. The simplest alternative is extending the perf_event lifetime to cover the task_work. The second is just silly, queueing a task_work while you know the event is going away makes no sense and is easily avoided by re-arranging how the event is marked STATE_DEAD and ensuring it goes through STATE_OFF on the way down. • https://git.kernel.org/stable/c/8bffa95ac19ff27c8261904f89d36c7fcf215d59 https://git.kernel.org/stable/c/78e1317a174edbfd1182599bf76c092a2877672c https://git.kernel.org/stable/c/517e6a301f34613bff24a8e35b5455884f2d83d8 •

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix u8 overflow By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases multiple times and eventually it will wrap around the maximum number (i.e., 255). This patch prevents this by adding a boundary check with L2CAP_MAX_CONF_RSP Btmon log: Bluetooth monitor ver 5.64 = Note: Linux version 6.1.0-rc2 (x86_64) 0.264594 = Note: Bluetooth subsystem version 2.22 0.264636 @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191 = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604 @ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741 = Open Index: 00:00:00:00:00:00 [hci0] 13.900426 (...) > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106 invalid packet size (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............ > ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561 invalid packet size (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@..... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@....... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@....... = bluetoothd: Bluetooth daemon 5.43 14.401828 > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753 invalid packet size (12 ! • https://git.kernel.org/stable/c/49d5867819ab7c744852b45509e8469839c07e0e https://git.kernel.org/stable/c/95f1847a361c7b4bf7d74c06ecb6968455082c1a https://git.kernel.org/stable/c/ad528fde0702903208d0a79d88d5a42ae3fc235b https://git.kernel.org/stable/c/9fdc79b571434af7bc742da40a3405f038b637a7 https://git.kernel.org/stable/c/f3fe6817156a2ad4b06f01afab04638a34d7c9a6 https://git.kernel.org/stable/c/19a78143961a197de8502f4f29c453b913dc3c29 https://git.kernel.org/stable/c/5550bbf709c323194881737fd290c4bada9e6ead https://git.kernel.org/stable/c/bcd70260ef56e0aee8a4fc6cd214a4199 • CWE-190: Integer Overflow or Wraparound •

CVSS: -EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication. • https://git.kernel.org/stable/c/c8b6fa4511a7900db9fb0353b630d4d2ed1ba99c https://git.kernel.org/stable/c/7665857f88557c372da35534165721156756f77f https://git.kernel.org/stable/c/72f651c96c8aadf087fd782d551bf7db648a8c2e https://git.kernel.org/stable/c/4d835efd561dfb9bf5409f11f4ecd428d5d29226 https://git.kernel.org/stable/c/1a075f4a549481ce6e8518d8379f193ccec6b746 https://git.kernel.org/stable/c/63dbbd8f1499b0a161e701a04aa50148d60bd1f7 https://git.kernel.org/stable/c/ae56d9a017724f130cf1a263dd82a78d2a6e3852 https://git.kernel.org/stable/c/12a88f572d6d94b5c0b72e2d1782cc2e9 •