CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42086 – iio: chemical: bme680: Fix overflows in compensate() functions
https://notcve.org/view.php?id=CVE-2024-42086
In the Linux kernel, the following vulnerability has been resolved: iio: chemical: bme680: Fix overflows in compensate() functions There are cases in the compensate functions of the driver that there could be overflows of variables due to bit shifting ops. These implications were initially discussed here [1] and they were mentioned in log message of Commit 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor"). [1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/ • https://git.kernel.org/stable/c/1b3bd8592780c87c5eddabbe98666b086bbaee36 https://git.kernel.org/stable/c/6fa31bbe2ea8665ee970258eb8320cbf231dbe9e https://git.kernel.org/stable/c/b0af334616ed425024bf220adda0f004806b5feb https://git.kernel.org/stable/c/c326551e99f5416986074ce78bef94f6a404b517 https://git.kernel.org/stable/c/7a13d1357658d3a3c1cd7b3b9543c805a6e5e6e9 https://git.kernel.org/stable/c/ba1bb3e2a38a7fef1c1818dd4f2d9abbfdde553a https://git.kernel.org/stable/c/b5967393d50e3c6e632efda3ea3fdde14c1bfd0e https://git.kernel.org/stable/c/3add41bbda92938e9a528d74659dfc552 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42085 – usb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock
https://notcve.org/view.php?id=CVE-2024-42085
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock When config CONFIG_USB_DWC3_DUAL_ROLE is selected, and trigger system to enter suspend status with below command: echo mem > /sys/power/state There will be a deadlock issue occurring. Detailed invoking path as below: dwc3_suspend_common() spin_lock_irqsave(&dwc->lock, flags); <-- 1st dwc3_gadget_suspend(dwc); dwc3_gadget_soft_disconnect(dwc); spin_lock_irqsave(&dwc->lock, flags); <-- 2nd This issue is exposed by commit c7ebd8149ee5 ("usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend") that removes the code of checking whether dwc->gadget_driver is NULL or not. It causes the following code is executed and deadlock occurs when trying to get the spinlock. In fact, the root cause is the commit 5265397f9442("usb: dwc3: Remove DWC3 locking during gadget suspend/resume") that forgot to remove the lock of otg mode. So, remove the redundant lock of otg mode during gadget suspend/resume. • https://git.kernel.org/stable/c/2fa487a9466760a4fb6f147aed6219379dabfc2e https://git.kernel.org/stable/c/5265397f94424eaea596026fd34dc7acf474dcec https://git.kernel.org/stable/c/7026576e89094aa9a0062aa6d10cba18aa99944c https://git.kernel.org/stable/c/d77e2b5104c51d3668b9717c825a4a06998efe63 https://git.kernel.org/stable/c/17e2956633ca560b95f1cbbb297cfc2adf650649 https://git.kernel.org/stable/c/f1274cfab183e69a7c7bafffcb4f50703c876276 https://git.kernel.org/stable/c/7838de15bb700c2898a7d741db9b1f3cbc86c136 •
CVSS: 5.7EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42084 – ftruncate: pass a signed offset
https://notcve.org/view.php?id=CVE-2024-42084
In the Linux kernel, the following vulnerability has been resolved: ftruncate: pass a signed offset The old ftruncate() syscall, using the 32-bit off_t misses a sign extension when called in compat mode on 64-bit architectures. As a result, passing a negative length accidentally succeeds in truncating to file size between 2GiB and 4GiB. Changing the type of the compat syscall to the signed compat_off_t changes the behavior so it instead returns -EINVAL. The native entry point, the truncate() syscall and the corresponding loff_t based variants are all correct already and do not suffer from this mistake. An unexpected file truncate flaw was found when opening files with specific parameters in the Linux kernel's file-system. This vulnerability allows a local user to corrupt specific files when having access to these files. • https://git.kernel.org/stable/c/3f6d078d4accfff8b114f968259a060bfdc7c682 https://git.kernel.org/stable/c/c329760749b5419769e57cb2be80955d2805f9c9 https://git.kernel.org/stable/c/f531d4bc6c5588d713359e42ed65e46816d841d8 https://git.kernel.org/stable/c/84bf6b64a1a0dfc6de7e1b1c776d58d608e7865a https://git.kernel.org/stable/c/dbb226d81cd02cee140139c2369791e6f61f2007 https://git.kernel.org/stable/c/5ae6af68410bdad6181ec82104bb9985a7a6a0fa https://git.kernel.org/stable/c/836359247b0403e0634bfbc83e5bb8063fad287a https://git.kernel.org/stable/c/930a4c369f74da26816eaaa71b5888d29 • CWE-96: Improper Neutralization of Directives in Statically Saved Code ('Static Code Injection') •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42083 – ionic: fix kernel panic due to multi-buffer handling
https://notcve.org/view.php?id=CVE-2024-42083
In the Linux kernel, the following vulnerability has been resolved: ionic: fix kernel panic due to multi-buffer handling Currently, the ionic_run_xdp() doesn't handle multi-buffer packets properly for XDP_TX and XDP_REDIRECT. When a jumbo frame is received, the ionic_run_xdp() first makes xdp frame with all necessary pages in the rx descriptor. And if the action is either XDP_TX or XDP_REDIRECT, it should unmap dma-mapping and reset page pointer to NULL for all pages, not only the first page. But it doesn't for SG pages. So, SG pages unexpectedly will be reused. It eventually causes kernel panic. Oops: general protection fault, probably for non-canonical address 0x504f4e4dbebc64ff: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.10.0-rc3+ #25 RIP: 0010:xdp_return_frame+0x42/0x90 Code: 01 75 12 5b 4c 89 e6 5d 31 c9 41 5c 31 d2 41 5d e9 73 fd ff ff 44 8b 6b 20 0f b7 43 0a 49 81 ed 68 01 00 00 49 29 c5 49 01 fd <41> 80 7d0 RSP: 0018:ffff99d00122ce08 EFLAGS: 00010202 RAX: 0000000000005453 RBX: ffff8d325f904000 RCX: 0000000000000001 RDX: 00000000670e1000 RSI: 000000011f90d000 RDI: 504f4e4d4c4b4a49 RBP: ffff99d003907740 R08: 0000000000000000 R09: 0000000000000000 R10: 000000011f90d000 R11: 0000000000000000 R12: ffff8d325f904010 R13: 504f4e4dbebc64fd R14: ffff8d3242b070c8 R15: ffff99d0039077c0 FS: 0000000000000000(0000) GS:ffff8d399f780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f41f6c85e38 CR3: 000000037ac30000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <IRQ> ? die_addr+0x33/0x90 ? exc_general_protection+0x251/0x2f0 ? asm_exc_general_protection+0x22/0x30 ? • https://git.kernel.org/stable/c/5377805dc1c02ad3721a9256f0eef9b4813952e7 https://git.kernel.org/stable/c/8ae401525ae84228a8986bb369224a6224e4d22f https://git.kernel.org/stable/c/e3f02f32a05009a688a87f5799e049ed6b55bab5 •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-42082 – xdp: Remove WARN() from __xdp_reg_mem_model()
https://notcve.org/view.php?id=CVE-2024-42082
In the Linux kernel, the following vulnerability has been resolved: xdp: Remove WARN() from __xdp_reg_mem_model() syzkaller reports a warning in __xdp_reg_mem_model(). The warning occurs only if __mem_id_init_hash_table() returns an error. It returns the error in two cases: 1. memory allocation fails; 2. rhashtable_init() fails when some fields of rhashtable_params struct are not initialized properly. The second case cannot happen since there is a static const rhashtable_params struct with valid fields. So, warning is only triggered when there is a problem with memory allocation. Thus, there is no sense in using WARN() to handle this error and it can be safely removed. WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299 CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299 Call Trace: xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344 xdp_test_run_setup net/bpf/test_run.c:188 [inline] bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377 bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267 bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240 __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649 __do_sys_bpf kernel/bpf/syscall.c:5738 [inline] __se_sys_bpf kernel/bpf/syscall.c:5736 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Found by Linux Verification Center (linuxtesting.org) with syzkaller. • https://git.kernel.org/stable/c/8d5d88527587516bd58ff0f3810f07c38e65e2be https://git.kernel.org/stable/c/1095b8efbb13a6a5fa583ed373ee1ccab29da2d0 https://git.kernel.org/stable/c/1d3e3b3aa2cbe9bc7db9a7f8673a9fa6d2990d54 https://git.kernel.org/stable/c/4e0c539ee265d5c6e7fa7d229cd4aa7bc01816e2 https://git.kernel.org/stable/c/14e51ea78b4ccacb7acb1346b9241bb790a2054c https://git.kernel.org/stable/c/f92298b0467fd77edc4c1a2c3e48833e69840ec4 https://git.kernel.org/stable/c/7e9f79428372c6eab92271390851be34ab26bfb4 https://access.redhat.com/security/cve/CVE-2024-42082 • CWE-770: Allocation of Resources Without Limits or Throttling •