Page 18 of 3478 results (0.007 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: mm/slub: Avoid list corruption when removing a slab from the full list Boot with slub_debug=UFPZ. If allocated object failed in alloc_consistency_checks, all objects of the slab will be marked as used, and then the slab will be removed from the partial list. When an object belonging to the slab got freed later, the remove_full() function is called. Because the slab is neither on the partial list nor on the full list, it eventually lead to a list corruption (actually a list poison being detected). So we need to mark and isolate the slab page with metadata corruption, do not put it back in circulation. Because the debug caches avoid all the fastpaths, reusing the frozen bit to mark slab page with metadata corruption seems to be fine. [ 4277.385669] list_del corruption, ffffea00044b3e50->next is LIST_POISON1 (dead000000000100) [ 4277.387023] ------------[ cut here ]------------ [ 4277.387880] kernel BUG at lib/list_debug.c:56! [ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G OE 6.6.1-1 #1 [ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs] [ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91 [ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082 [ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000 [ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff [ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0 [ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910 [ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0 [ 4277.404049] FS: 0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000 [ 4277.405357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0 [ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4277.410000] PKRU: 55555554 [ 4277.410645] Call Trace: [ 4277.411234] <TASK> [ 4277.411777] ? die+0x32/0x80 [ 4277.412439] ? do_trap+0xd6/0x100 [ 4277.413150] ? • https://git.kernel.org/stable/c/643b113849d8faa68c9f01c3c9d929bfbffd50bd https://git.kernel.org/stable/c/33a213c04faff6c3a7fe77e947db81bc7270fe32 https://git.kernel.org/stable/c/943c0f601cd28c1073b92b5f944c6c6c2643e709 https://git.kernel.org/stable/c/dbc16915279a548a204154368da23d402c141c81 •

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

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to drop all discards after creating snapshot on lvm device Piergiorgio reported a bug in bugzilla as below: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 969 at fs/f2fs/segment.c:1330 RIP: 0010:__submit_discard_cmd+0x27d/0x400 [f2fs] Call Trace: __issue_discard_cmd+0x1ca/0x350 [f2fs] issue_discard_thread+0x191/0x480 [f2fs] kthread+0xcf/0x100 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x1a/0x30 w/ below testcase, it can reproduce this bug quickly: - pvcreate /dev/vdb - vgcreate myvg1 /dev/vdb - lvcreate -L 1024m -n mylv1 myvg1 - mount /dev/myvg1/mylv1 /mnt/f2fs - dd if=/dev/zero of=/mnt/f2fs/file bs=1M count=20 - sync - rm /mnt/f2fs/file - sync - lvcreate -L 1024m -s -n mylv1-snapshot /dev/myvg1/mylv1 - umount /mnt/f2fs The root cause is: it will update discard_max_bytes of mounted lvm device to zero after creating snapshot on this lvm device, then, __submit_discard_cmd() will pass parameter @nr_sects w/ zero value to __blkdev_issue_discard(), it returns a NULL bio pointer, result in panic. This patch changes as below for fixing: 1. Let's drop all remained discards in f2fs_unfreeze() if snapshot of lvm device is created. 2. Checking discard_max_bytes before submitting discard during __submit_discard_cmd(). • https://git.kernel.org/stable/c/35ec7d5748849762008e8ae9f8ad2766229d5794 https://git.kernel.org/stable/c/ed24ab98242f8d22b66fbe0452c97751b5ea4e22 https://git.kernel.org/stable/c/15136c3861a3341db261ebdbb6ae4ae1765635e2 https://git.kernel.org/stable/c/bc8aeb04fd80cb8cfae3058445c84410fd0beb5e •

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

In the Linux kernel, the following vulnerability has been resolved: i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs() if (dev->boardinfo && dev->boardinfo->init_dyn_addr) ^^^ here check "init_dyn_addr" i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...) ^^^^ free "dyn_addr" Fix copy/paste error "dyn_addr" by replacing it with "init_dyn_addr". • https://git.kernel.org/stable/c/3a379bbcea0af6280e1ca0d1edfcf4e68cde6ee0 https://git.kernel.org/stable/c/c2f0ce241154b04f2fc150ff16ad82d9b8fdfa4a https://git.kernel.org/stable/c/093ecc6d82ff1d2e0cbf6f2000438b6c698145cb https://git.kernel.org/stable/c/0cb21f1ea3a2e19ee314a8fcf95461b5c453c59e https://git.kernel.org/stable/c/991e33a99fd3b5d432f0629565f532f563fe019a https://git.kernel.org/stable/c/ce30d11b39e8d637fed4704a5b43e9d556990475 https://git.kernel.org/stable/c/0e8ab955c6d06f9d907761c07c02d1492f0a8ac1 https://git.kernel.org/stable/c/3082990592f7c6d7510a9133afa46e31b •

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

In the Linux kernel, the following vulnerability has been resolved: nfsd: make sure exp active before svc_export_show The function `e_show` was called with protection from RCU. This only ensures that `exp` will not be freed. Therefore, the reference count for `exp` can drop to zero, which will trigger a refcount use-after-free warning when `exp_get` is called. To resolve this issue, use `cache_get_rcu` to ensure that `exp` remains active. ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 3 PID: 819 at lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 3 UID: 0 PID: 819 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120 ... Call Trace: <TASK> e_show+0x20b/0x230 [nfsd] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e • https://git.kernel.org/stable/c/bf18f163e89c52e09c96534db45c4274273a0b34 https://git.kernel.org/stable/c/e2fa0d0e327279a8defb87b263cd0bf288fd9261 https://git.kernel.org/stable/c/7fd29d284b55c2274f7a748e6c5f25b4758b8da5 https://git.kernel.org/stable/c/6cefcadd34e3c71c81ea64b899a0daa86314a51a https://git.kernel.org/stable/c/7d8f7816bebcd2e7400bb4d786eccb8f33c9f9ec https://git.kernel.org/stable/c/1cecfdbc6bfc89c516d286884c7f29267b95de2b https://git.kernel.org/stable/c/7365d1f8de63cffdbbaa2287ce0205438e1a922f https://git.kernel.org/stable/c/be8f982c369c965faffa198b46060f885 •

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

In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer The AD7923 was updated to support devices with 8 channels, but the size of tx_buf and ring_xfer was not increased accordingly, leading to a potential buffer overflow in ad7923_update_scan_mode(). • https://git.kernel.org/stable/c/851644a60d200c9a294de5a5594004bcf13d34c7 https://git.kernel.org/stable/c/00663d3e000c31d0d49ef86a809f5c107c2d09cd https://git.kernel.org/stable/c/e5cac32721997cb8bcb208a29f4598b3faf46338 https://git.kernel.org/stable/c/218ecc35949129171ca39bcc0d407c8dc4cd0bbc https://git.kernel.org/stable/c/3a4187ec454e19903fd15f6e1825a4b84e59a4cd •