CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42063 – bpf: Mark bpf prog stack with kmsan_unposion_memory in interpreter mode
https://notcve.org/view.php?id=CVE-2024-42063
In the Linux kernel, the following vulnerability has been resolved: bpf: Mark bpf prog stack with kmsan_unposion_memory in interpreter mode syzbot reported uninit memory usages during map_{lookup,delete}_elem. ========== BUG: KMSAN: uninit-value in __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline] BUG: KMSAN: uninit-value in dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796 __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline] dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796 ____bpf_map_lookup_elem kernel/bpf/helpers.c:42 [inline] bpf_map_lookup_elem+0x5c/0x80 kernel/bpf/helpers.c:38 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run256+0xb5/0xe0 kernel/bpf/core.c:2237 ========== The reproducer should be in the interpreter mode. The C reproducer is trying to run the following bpf prog: 0: (18) r0 = 0x0 2: (18) r1 = map[id:49] 4: (b7) r8 = 16777216 5: (7b) *(u64 *)(r10 -8) = r8 6: (bf) r2 = r10 7: (07) r2 += -229 ^^^^^^^^^^ 8: (b7) r3 = 8 9: (b7) r4 = 0 10: (85) call dev_map_lookup_elem#1543472 11: (95) exit It is due to the "void *key" (r2) passed to the helper. bpf allows uninit stack memory access for bpf prog with the right privileges. This patch uses kmsan_unpoison_memory() to mark the stack as initialized. This should address different syzbot reports on the uninit "void *key" argument during map_{lookup,delete}_elem. • https://git.kernel.org/stable/c/b30f3197a6cd080052d5d4973f9a6b479fd9fff5 https://git.kernel.org/stable/c/d812ae6e02bd6e6a9cd1fdb09519c2f33e875faf https://git.kernel.org/stable/c/3189983c26108cf0990e5c46856dc9feb9470d12 https://git.kernel.org/stable/c/e8742081db7d01f980c6161ae1e8a1dbc1e30979 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52887 – net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new
https://notcve.org/view.php?id=CVE-2023-52887
In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new This patch enhances error handling in scenarios with RTS (Request to Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE backtraces with a new error handling method. This provides clearer error messages and allows for the early termination of problematic sessions. Previously, sessions were only released at the end of j1939_xtp_rx_rts(). Potentially this could be reproduced with something like: testj1939 -r vcan0:0x80 & while true; do # send first RTS cansend vcan0 18EC8090#1014000303002301; # send second RTS cansend vcan0 18EC8090#1014000303002301; # send abort cansend vcan0 18EC8090#ff00000000002301; done • https://git.kernel.org/stable/c/9d71dd0c70099914fcd063135da3c580865e924c https://git.kernel.org/stable/c/ed581989d7ea9df6f8646beba2341e32cd49a1f9 https://git.kernel.org/stable/c/f6c839e717901dbd6b1c1ca807b6210222eb70f6 https://git.kernel.org/stable/c/1762ca80c2b72dd1b5821c5e347713ae696276ea https://git.kernel.org/stable/c/26b18dd30e63d4fd777be429148e8e4ed66f60b2 https://git.kernel.org/stable/c/177e33b655d35d72866b50aec84307119dc5f3d4 https://git.kernel.org/stable/c/0bc0a7416ea73f79f915c9a05ac0858dff65cfed https://git.kernel.org/stable/c/d3e2904f71ea0fe7eaff1d68a2b0363c8 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41098 – ata: libata-core: Fix null pointer dereference on error
https://notcve.org/view.php?id=CVE-2024-41098
In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Fix null pointer dereference on error If the ata_port_alloc() call in ata_host_alloc() fails, ata_host_release() will get called. However, the code in ata_host_release() tries to free ata_port struct members unconditionally, which can lead to the following: BUG: unable to handle page fault for address: 0000000000003990 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata] Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41 RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246 RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0 RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68 R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004 R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006 FS: 00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? • https://git.kernel.org/stable/c/633273a3ed1cf37ced90475b0f95cf81deab04f1 https://git.kernel.org/stable/c/d9c4df80b1b009de1eb77c07e3bb4d45bd212aa5 https://git.kernel.org/stable/c/56e62977eaaae3eb7122ee2cf9b720b6703114a9 https://git.kernel.org/stable/c/e83405e75d90694ee6a5d898f7f0473ac2686054 https://git.kernel.org/stable/c/221e3b1297e74fdec32d0f572f4dcb2260a0a2af https://git.kernel.org/stable/c/0f0d37c154bb108730c90a91aa31e3170e827962 https://git.kernel.org/stable/c/119c97ace2a9ffcf4dc09a23bb057d6c281aff28 https://git.kernel.org/stable/c/8a8ff7e3b736a70d7b7c8764cbcd2724d •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-41097 – usb: atm: cxacru: fix endpoint checking in cxacru_bind()
https://notcve.org/view.php?id=CVE-2024-41097
In the Linux kernel, the following vulnerability has been resolved: usb: atm: cxacru: fix endpoint checking in cxacru_bind() Syzbot is still reporting quite an old issue [1] that occurs due to incomplete checking of present usb endpoints. As such, wrong endpoints types may be used at urb sumbitting stage which in turn triggers a warning in usb_submit_urb(). Fix the issue by verifying that required endpoint types are present for both in and out endpoints, taking into account cmd endpoint type. Unfortunately, this patch has not been tested on real hardware. [1] Syzbot report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Call Trace: cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:517 [inline] really_probe+0x23c/0xcd0 drivers/base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/core.c:3354 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293 • https://git.kernel.org/stable/c/902ffc3c707c1d459ea57428a619a807cbe412f9 https://git.kernel.org/stable/c/5159a81924311c1ec786ad9fdef784ead8676a6a https://git.kernel.org/stable/c/23926d316d2836315cb113569f91393266eb5b47 https://git.kernel.org/stable/c/75ddbf776dd04a09fb9e5267ead5d0c989f84506 https://git.kernel.org/stable/c/1aac4be1aaa5177506219f01dce5e29194e5e95a https://git.kernel.org/stable/c/5584c776a1af7807ca815ee6265f2c1429fc5727 https://git.kernel.org/stable/c/f536f09eb45e4de8d1b9accee9d992aa1846f1d4 https://git.kernel.org/stable/c/ac9007520e392541a29daebaae8b91090 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 6.7EPSS: 0%CPEs: 4EXPL: 0CVE-2024-41096 – PCI/MSI: Fix UAF in msi_capability_init
https://notcve.org/view.php?id=CVE-2024-41096
In the Linux kernel, the following vulnerability has been resolved: PCI/MSI: Fix UAF in msi_capability_init KFENCE reports the following UAF: BUG: KFENCE: use-after-free read in __pci_enable_msi_range+0x2c0/0x488 Use-after-free read at 0x0000000024629571 (in kfence-#12): __pci_enable_msi_range+0x2c0/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 kfence-#12: 0x0000000008614900-0x00000000e06c228d, size=104, cache=kmalloc-128 allocated by task 81 on cpu 7 at 10.808142s: __kmem_cache_alloc_node+0x1f0/0x2bc kmalloc_trace+0x44/0x138 msi_alloc_desc+0x3c/0x9c msi_domain_insert_msi_desc+0x30/0x78 msi_setup_msi_desc+0x13c/0x184 __pci_enable_msi_range+0x258/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 freed by task 81 on cpu 7 at 10.811436s: msi_domain_free_descs+0xd4/0x10c msi_domain_free_locked.part.0+0xc0/0x1d8 msi_domain_alloc_irqs_all_locked+0xb4/0xbc pci_msi_setup_msi_irqs+0x30/0x4c __pci_enable_msi_range+0x2a8/0x488 pci_alloc_irq_vectors_affinity+0xec/0x14c pci_alloc_irq_vectors+0x18/0x28 Descriptor allocation done in: __pci_enable_msi_range msi_capability_init msi_setup_msi_desc msi_insert_msi_desc msi_domain_insert_msi_desc msi_alloc_desc ... Freed in case of failure in __msi_domain_alloc_locked() __pci_enable_msi_range msi_capability_init pci_msi_setup_msi_irqs msi_domain_alloc_irqs_all_locked msi_domain_alloc_locked __msi_domain_alloc_locked => fails msi_domain_free_locked ... That failure propagates back to pci_msi_setup_msi_irqs() in msi_capability_init() which accesses the descriptor for unmasking in the error exit path. Cure it by copying the descriptor and using the copy for the error exit path unmask operation. [ tglx: Massaged change log ] A use after free vulnerability was found in the Linux Kernel. Failure propagates back to pci_msi_setup_msi_irqs() in msi_capability_init(), which accesses the descriptor for unmasking in the error exit path, leading to a loss of confidentiality, integrity, and availability. • https://git.kernel.org/stable/c/bf6e054e0e3fbc9614355b760e18c8a14f952a4e https://git.kernel.org/stable/c/0ae40b2d0a5de6b045504098e365d4fdff5bbeba https://git.kernel.org/stable/c/ff1121d2214b794dc1772081f27bdd90721a84bc https://git.kernel.org/stable/c/45fc8d20e0768ab0a0ad054081d0f68aa3c83976 https://git.kernel.org/stable/c/9eee5330656bf92f51cb1f09b2dc9f8cf975b3d1 https://access.redhat.com/security/cve/CVE-2024-41096 https://bugzilla.redhat.com/show_bug.cgi?id=2300491 • CWE-416: Use After Free •