CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52922 – can: bcm: Fix UAF in bcm_proc_show()
https://notcve.org/view.php?id=CVE-2023-52922
In the Linux kernel, the following vulnerability has been resolved: can: bcm: Fix UAF in bcm_proc_show() BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80 Read of size 8 at addr ffff888155846230 by task cat/7862 CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 #230 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xd5/0x150 print_report+0xc1/0x5e0 kasan_report+0xba/0xf0 bcm_proc_show+0x969/0xa80 seq_read_iter+0x4f6/0x1260 seq_read+0x165/0x210 proc_reg_read+0x227/0x300 vfs_read+0x1d5/0x8d0 ksys_read+0x11e/0x240 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Allocated by task 7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x9e/0xa0 bcm_sendmsg+0x264b/0x44e0 sock_sendmsg+0xda/0x180 ____sys_sendmsg+0x735/0x920 ___sys_sendmsg+0x11d/0x1b0 __sys_sendmsg+0xfa/0x1d0 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x27/0x40 ____kasan_slab_free+0x161/0x1c0 slab_free_freelist_hook+0x119/0x220 __kmem_cache_free+0xb4/0x2e0 rcu_core+0x809/0x1bd0 bcm_op is freed before procfs entry be removed in bcm_release(), this lead to bcm_proc_show() may read the freed bcm_op. • https://git.kernel.org/stable/c/ffd980f976e7fd666c2e61bf8ab35107efd11828 https://git.kernel.org/stable/c/11b8e27ed448baa385d90154a141466bd5e92f18 https://git.kernel.org/stable/c/9b58d36d0c1ea29a9571e0222a9c29df0ccfb7ff https://git.kernel.org/stable/c/9533dbfac0ff7edd77a5fa2c24974b1d66c8b0a6 https://git.kernel.org/stable/c/cf254b4f68e480e73dab055014e002b77aed30ed https://git.kernel.org/stable/c/3c3941bb1eb53abe7d640ffee5c4d6b559829ab3 https://git.kernel.org/stable/c/995f47d76647708ec26c6e388663ad4f3f264787 https://git.kernel.org/stable/c/dfd0aa26e9a07f2ce546ccf8304ead6a2 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-53102 – nvme: make keep-alive synchronous operation
https://notcve.org/view.php?id=CVE-2024-53102
In the Linux kernel, the following vulnerability has been resolved: nvme: make keep-alive synchronous operation The nvme keep-alive operation, which executes at a periodic interval, could potentially sneak in while shutting down a fabric controller. This may lead to a race between the fabric controller admin queue destroy code path (invoked while shutting down controller) and hw/hctx queue dispatcher called from the nvme keep-alive async request queuing operation. This race could lead to the kernel crash shown below: Call Trace: autoremove_wake_function+0x0/0xbc (unreliable) __blk_mq_sched_dispatch_requests+0x114/0x24c blk_mq_sched_dispatch_requests+0x44/0x84 blk_mq_run_hw_queue+0x140/0x220 nvme_keep_alive_work+0xc8/0x19c [nvme_core] process_one_work+0x200/0x4e0 worker_thread+0x340/0x504 kthread+0x138/0x140 start_kernel_thread+0x14/0x18 While shutting down fabric controller, if nvme keep-alive request sneaks in then it would be flushed off. The nvme_keep_alive_end_io function is then invoked to handle the end of the keep-alive operation which decrements the admin->q_usage_counter and assuming this is the last/only request in the admin queue then the admin->q_usage_counter becomes zero. If that happens then blk-mq destroy queue operation (blk_mq_destroy_ queue()) which could be potentially running simultaneously on another cpu (as this is the controller shutdown code path) would forward progress and deletes the admin queue. So, now from this point onward we are not supposed to access the admin queue resources. However the issue here's that the nvme keep-alive thread running hw/hctx queue dispatch operation hasn't yet finished its work and so it could still potentially access the admin queue resource while the admin queue had been already deleted and that causes the above crash. This fix helps avoid the observed crash by implementing keep-alive as a synchronous operation so that we decrement admin->q_usage_counter only after keep-alive command finished its execution and returns the command status back up to its caller (blk_execute_rq()). • https://git.kernel.org/stable/c/afa229465399f89d3af9d72ced865144c9748846 https://git.kernel.org/stable/c/1a1bcca5c9efd2c72c8d2fcbadf2d673cceb2ea7 https://git.kernel.org/stable/c/ccc1d82dfaad0ad27d21139da22e57add73d2a5e https://git.kernel.org/stable/c/d06923670b5a5f609603d4a9fee4dec02d38de9c •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-53101 – fs: Fix uninitialized value issue in from_kuid and from_kgid
https://notcve.org/view.php?id=CVE-2024-53101
In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0. • https://git.kernel.org/stable/c/a0c77e5e3dcbffc7c6080ccc89c037f0c86496cf https://git.kernel.org/stable/c/17ecb40c5cc7755a321fb6148cba5797431ee5b8 https://git.kernel.org/stable/c/9db25c2b41c34963c3ccf473b08171f87670652e https://git.kernel.org/stable/c/b3e612bd8f64ce62e731e95f635e06a2efe3c80c https://git.kernel.org/stable/c/5a72b0d3497b818d8f000c347a7c11801eb27bfc https://git.kernel.org/stable/c/1cb5bfc5bfc651982b6203c224d49b7ddacf28bc https://git.kernel.org/stable/c/1c28bca1256aecece6e94b26b85cd07e08b0dc90 https://git.kernel.org/stable/c/15f34347481648a567db67fb473c23bef •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-53100 – nvme: tcp: avoid race between queue_lock lock and destroy
https://notcve.org/view.php?id=CVE-2024-53100
In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc ("nvme-tcp: don't access released socket during error recovery") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? • https://git.kernel.org/stable/c/4f946479b326a3cbb193f2b8368aed9269514c35 https://git.kernel.org/stable/c/975cb1d2121511584695d0e47fdb90e6782da007 https://git.kernel.org/stable/c/e15cebc1b21856944b387f4abd03b66bd3d4f027 https://git.kernel.org/stable/c/782373ba27660ba7d330208cf5509ece6feb4545 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-53099 – bpf: Check validity of link->type in bpf_link_show_fdinfo()
https://notcve.org/view.php?id=CVE-2024-53099
In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed. • https://git.kernel.org/stable/c/d5092b0a1aaf35d77ebd8d33384d7930bec5cb5d https://git.kernel.org/stable/c/b3eb1b6a9f745d6941b345f0fae014dc8bb06d36 https://git.kernel.org/stable/c/8421d4c8762bd022cb491f2f0f7019ef51b4f0a7 •