Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2021-47453 State: PUBLISHED Published: 2024-05-22T06:19:43.374Z Last Updated: 2025-05-04T07:11:15.700Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ice: Avoid crash from unnecessary IDA free In the remove path, there is an attempt to free the aux_idx IDA whether it was allocated or not. This can potentially cause a crash when unloading the driver on systems that do not initialize support for RDMA. But, this free cannot be gated by the status bit for RDMA, since it is allocated if the driver detects support for RDMA at probe time, but the driver can enter into a state where RDMA is not supported after the IDA has b
ts support for RDMA at probe time, but the driver can enter into a state where RDMA is not supported after the IDA has been allocated at probe time and this would lead to a memory leak. Initialize aux_idx to an invalid value and check for a valid value when unloading to determine if an IDA free is necessary. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/777682e59840e24e6c5672197e6ffbcf4bff823b - https://git.kernel.org/stable/c/73e30a62b19b9fbb4e6a3465c59da186630d5f2e
CVE ID: CVE-2021-47454 State: PUBLISHED Published: 2024-05-22T06:19:44.040Z Last Updated: 2025-05-04T12:41:30.543Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powerpc/smp: do not decrement idle task preempt count in CPU offline With PREEMPT_COUNT=y, when a CPU is offlined and then onlined again, we get: BUG: scheduling while atomic: swapper/1/0/0x00000000 no locks held by swapper/1/0. CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.15.0-rc2+ #100 Call Trace: dump_stack_lvl+0xac/0x108 __schedule_bug+0xac/0xe0 __schedule+0xcf8/0x10d0 schedule_idle+0x3c/0x70 do_idle+0x2d8/0x4a0 cpu_startup_entry+0x38/0x40 start_secondary+0x2ec/0x3a
schedule+0xcf8/0x10d0 schedule_idle+0x3c/0x70 do_idle+0x2d8/0x4a0 cpu_startup_entry+0x38/0x40 start_secondary+0x2ec/0x3a0 start_secondary_prolog+0x10/0x14 This is because powerpc's arch_cpu_idle_dead() decrements the idle task's preempt count, for reasons explained in commit a7c2bb8279d2 ("powerpc: Re-enable preemption before cpu_die()"), specifically "start_secondary() expects a preempt_count() of 0." However, since commit 2c669ef6979c ("powerpc/preempt: Don't touch the idle task's preempt_count during hotplug") and commit f1a0a376ca0c ("sched/core: Initialize the idle task with preemption disabled"), that justification no longer holds. The idle task isn't supposed to re-enable preemption,
k with preemption disabled"), that justification no longer holds. The idle task isn't supposed to re-enable preemption, so remove the vestigial preempt_enable() from the CPU offline path. Tested with pseries and powernv in qemu, and pseries on PowerVM. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/53770a411559cf7bc0906d1df319cc533d2f4f58 - https://git.kernel.org/stable/c/3ea0b497a7a2fff6a4b7090310c9f52c91975934 - https://git.kernel.org/stable/c/787252a10d9422f3058df9a4821f389e5326c440
CVE ID: CVE-2021-47455 State: PUBLISHED Published: 2024-05-22T06:19:44.700Z Last Updated: 2025-11-03T17:30:57.924Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ptp: Fix possible memory leak in ptp_clock_register() I got memory leak as follows when doing fault injection test: unreferenced object 0xffff88800906c618 (size 8): comm "i2c-idt82p33931", pid 4421, jiffies 4294948083 (age 13.188s) hex dump (first 8 bytes): 70 74 70 30 00 00 00 00 ptp0.... backtrace: [<00000000312ed458>] __kmalloc_track_caller+0x19f/0x3a0 [<0000000079f6e2ff>] kvasprintf+0xb5/0x150 [<0000000026aae54f>] kvasprintf_const+0x60/0x190 [<00000000f323a5f7>] ko
x3a0 [<0000000079f6e2ff>] kvasprintf+0xb5/0x150 [<0000000026aae54f>] kvasprintf_const+0x60/0x190 [<00000000f323a5f7>] kobject_set_name_vargs+0x56/0x150 [<000000004e35abdd>] dev_set_name+0xc0/0x100 [<00000000f20cfe25>] ptp_clock_register+0x9f4/0xd30 [ptp] [<000000008bb9f0de>] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33] When posix_clock_register() returns an error, the name allocated in dev_set_name() will be leaked, the put_device() should be used to give up the device reference, then the name will be freed in kobject_cleanup() and other memory will be freed in ptp_clock_release(). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel
_release(). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/f1c96d8085588e1b997a96214b409ac3be20b524 - https://git.kernel.org/stable/c/95c0a0c5ec8839f8f21672be786e87a100319ca8 - https://git.kernel.org/stable/c/4225fea1cb28370086e17e82c0f69bec2779dca0
CVE ID: CVE-2021-47456 State: PUBLISHED Published: 2024-05-22T06:19:45.363Z Last Updated: 2025-05-04T07:11:19.120Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: peak_pci: peak_pci_remove(): fix UAF When remove the module peek_pci, referencing 'chan' again after releasing 'dev' will cause UAF. Fix this by releasing 'dev' later. The following log reveals it: [ 35.961814 ] BUG: KASAN: use-after-free in peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537 [ 35.965513 ] Call Trace: [ 35.965718 ] dump_stack_lvl+0xa8/0xd1 [ 35.966028 ] print_address_description+0x87/0
obe/5537 [ 35.965513 ] Call Trace: [ 35.965718 ] dump_stack_lvl+0xa8/0xd1 [ 35.966028 ] print_address_description+0x87/0x3b0 [ 35.966420 ] kasan_report+0x172/0x1c0 [ 35.966725 ] ? peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.967137 ] ? trace_irq_enable_rcuidle+0x10/0x170 [ 35.967529 ] ? peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.967945 ] __asan_report_load8_noabort+0x14/0x20 [ 35.968346 ] peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.968752 ] pci_device_remove+0xa9/0x250 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/1c616528ba4aeb1125a06b407572ab7b56acae38 - https://git.kernel.org/stable/c/447d44cd2f67a20b596ede3ca3cd6
el.org/stable/c/1c616528ba4aeb1125a06b407572ab7b56acae38 - https://git.kernel.org/stable/c/447d44cd2f67a20b596ede3ca3cd67086dfd9ca9 - https://git.kernel.org/stable/c/34914971bb3244db4ce2be44e9438a9b30c56250 - https://git.kernel.org/stable/c/adbda14730aacce41c0d3596415aa39ad63eafd9 - https://git.kernel.org/stable/c/1248582e47a9f7ce0ecd156c39fc61f8b6aa3699 - https://git.kernel.org/stable/c/28f28e4bc3a5e0051faa963f10b778ab38c1db69 - https://git.kernel.org/stable/c/0e5afdc2315b0737edcf55bede4ee1640d2d464d - https://git.kernel.org/stable/c/949fe9b35570361bc6ee2652f89a0561b26eec98
CVE ID: CVE-2021-47457 State: PUBLISHED Published: 2024-05-22T06:19:46.021Z Last Updated: 2025-05-04T07:11:20.213Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: isotp: isotp_sendmsg(): add result check for wait_event_interruptible() Using wait_event_interruptible() to wait for complete transmission, but do not check the result of wait_event_interruptible() which can be interrupted. It will result in TX buffer has multiple accessors and the later process interferes with the previous process. Following is one of the problems reported by syzbot. ============================================================= WARNING: CPU: 0 PI
one of the problems reported by syzbot. ============================================================= WARNING: CPU: 0 PID: 0 at net/can/isotp.c:840 isotp_tx_timer_handler+0x2e0/0x4c0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc7+ #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014 RIP: 0010:isotp_tx_timer_handler+0x2e0/0x4c0 Call Trace: <IRQ> ? isotp_setsockopt+0x390/0x390 __hrtimer_run_queues+0xb8/0x610 hrtimer_run_softirq+0x91/0xd0 ? rcu_read_lock_sched_held+0x4d/0x80 __do_softirq+0xe8/0x553 irq_exit_rcu+0xf8/0x100 sysvec_apic_timer_interrupt+0x9e/0xc0 </IRQ> asm_sysvec_apic_timer_interrupt+0x12/0x20 Add result check for wait_event_interruptibl
_timer_interrupt+0x9e/0xc0 </IRQ> asm_sysvec_apic_timer_interrupt+0x12/0x20 Add result check for wait_event_interruptible() in isotp_sendmsg() to avoid multiple accessers for tx buffer. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/053bc12df0d6097c1126d0e14fa778a0a8faeb64 - https://git.kernel.org/stable/c/a76abedd2be3926d6deba236a935c7f98abf9110 - https://git.kernel.org/stable/c/9acf636215a6ce9362fe618e7da4913b8bfe84c8
CVE ID: CVE-2021-47458 State: PUBLISHED Published: 2024-05-22T06:19:46.675Z Last Updated: 2025-05-04T07:11:21.260Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ocfs2: mount fails with buffer overflow in strlen Starting with kernel 5.11 built with CONFIG_FORTIFY_SOURCE mouting an ocfs2 filesystem with either o2cb or pcmk cluster stack fails with the trace below. Problem seems to be that strings for cluster stack and cluster name are not guaranteed to be null terminated in the disk representation, while strlcpy assumes that the source string is always null terminated. This causes a read outside of the source string triggering t
y assumes that the source string is always null terminated. This causes a read outside of the source string triggering the buffer overflow detection. detected buffer overflow in strlen ------------[ cut here ]------------ kernel BUG at lib/string.c:1149! invalid opcode: 0000 [#1] SMP PTI CPU: 1 PID: 910 Comm: mount.ocfs2 Not tainted 5.14.0-1-amd64 #1 Debian 5.14.6-2 RIP: 0010:fortify_panic+0xf/0x11 ... Call Trace: ocfs2_initialize_super.isra.0.cold+0xc/0x18 [ocfs2] ocfs2_fill_super+0x359/0x19b0 [ocfs2] mount_bdev+0x185/0x1b0 legacy_get_tree+0x27/0x40 vfs_get_tree+0x25/0xb0 path_mount+0x454/0xa20 __x64_sys_mount+0x103/0x140 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Addi
path_mount+0x454/0xa20 __x64_sys_mount+0x103/0x140 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/ac011cb3ff7a76b3e0e6e77158ee4ba2f929e1fb - https://git.kernel.org/stable/c/4b74ddcc22ee6455946e80a9c4808801f8f8561e - https://git.kernel.org/stable/c/232ed9752510de4436468b653d145565669c8498 - https://git.kernel.org/stable/c/7623b1035ca2d17bde0f6a086ad6844a34648df1 - https://git.kernel.org/stable/c/d3a83576378b4c904f711598dde2c5e881c4295c - https://git.kernel.org/stable/c/93be0eeea14cf39235e585c8f56df3b3859deaad - https://git.kernel.org/stable/c/0e677ea5b739
https://git.kernel.org/stable/c/93be0eeea14cf39235e585c8f56df3b3859deaad - https://git.kernel.org/stable/c/0e677ea5b7396f715a76b6b0ef441430e4c4b57f - https://git.kernel.org/stable/c/b15fa9224e6e1239414525d8d556d824701849fc
CVE ID: CVE-2021-47459 State: PUBLISHED Published: 2024-05-22T06:23:21.061Z Last Updated: 2025-05-04T07:11:22.671Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: j1939: j1939_netdev_start(): fix UAF for rx_kref of j1939_priv It will trigger UAF for rx_kref of j1939_priv as following. cpu0 cpu1 j1939_sk_bind(socket0, ndev0, ...) j1939_netdev_start j1939_sk_bind(socket1, ndev0, ...) j1939_netdev_start j1939_priv_set j1939_priv_get_by_ndev_locked j1939_jsk_add ..... j1939_netdev_stop kref_put_lock(&priv->rx_kref, ...) kref_get(&priv->rx_kref, ...) REFCOUNT_WARN("addition on 0;...") ============================================
kref, ...) kref_get(&priv->rx_kref, ...) REFCOUNT_WARN("addition on 0;...") ==================================================== refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 20874 at lib/refcount.c:25 refcount_warn_saturate+0x169/0x1e0 RIP: 0010:refcount_warn_saturate+0x169/0x1e0 Call Trace: j1939_netdev_start+0x68b/0x920 j1939_sk_bind+0x426/0xeb0 ? security_socket_bind+0x83/0xb0 The rx_kref's kref_get() and kref_put() should use j1939_netdev_lock to protect. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/a0e47d2833b4f65e6c799f28c6b636d36b8b936d - https://git.kernel.org/stable/c/864e77771a24c877aaf5
/git.kernel.org/stable/c/a0e47d2833b4f65e6c799f28c6b636d36b8b936d - https://git.kernel.org/stable/c/864e77771a24c877aaf53aee019f78619cbcd668 - https://git.kernel.org/stable/c/6e8811707e2df0c6ba920f0cad3a3bca7b42132f - https://git.kernel.org/stable/c/d9d52a3ebd284882f5562c88e55991add5d01586
CVE ID: CVE-2021-47460 State: PUBLISHED Published: 2024-05-22T06:23:21.724Z Last Updated: 2025-05-04T12:41:32.834Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix data corruption after conversion from inline format Commit 6dbf7bb55598 ("fs: Don't invalidate page buffers in block_write_full_page()") uncovered a latent bug in ocfs2 conversion from inline inode format to a normal inode format. The code in ocfs2_convert_inline_data_to_extents() attempts to zero out the whole cluster allocated for file data by grabbing, zeroing, and dirtying all pages covering this cluster. However these pages are beyond i_size, thus write
ta by grabbing, zeroing, and dirtying all pages covering this cluster. However these pages are beyond i_size, thus writeback code generally ignores these dirty pages and no blocks were ever actually zeroed on the disk. This oversight was fixed by commit 693c241a5f6a ("ocfs2: No need to zero pages past i_size.") for standard ocfs2 write path, inline conversion path was apparently forgotten; the commit log also has a reasoning why the zeroing actually is not needed. After commit 6dbf7bb55598, things became worse as writeback code stopped invalidating buffers on pages beyond i_size and thus these pages end up with clean PageDirty bit but with buffers attached to these pages being still dirty. S
_size and thus these pages end up with clean PageDirty bit but with buffers attached to these pages being still dirty. So when a file is converted from inline format, then writeback triggers, and then the file is grown so that these pages become valid, the invalid dirtiness state is preserved, mark_buffer_dirty() does nothing on these pages (buffers are already dirty) but page is never written back because it is clean. So data written to these pages is lost once pages are reclaimed. Simple reproducer for the problem is: xfs_io -f -c "pwrite 0 2000" -c "pwrite 2000 2000" -c "fsync" \ -c "pwrite 4000 2000" ocfs2_file After unmounting and mounting the fs again, you can observe that end of 'ocfs
"fsync" \ -c "pwrite 4000 2000" ocfs2_file After unmounting and mounting the fs again, you can observe that end of 'ocfs2_file' has lost its contents. Fix the problem by not doing the pointless zeroing during conversion from inline format similarly as in the standard write path. [akpm@linux-foundation.org: fix whitespace, per Joseph] Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/560edd14de2bf9dbc0129681eeb4d5ef87cc105f - https://git.kernel.org/stable/c/8e6bfb4f70168ddfd32fb6dc028ad52faaf1f32e - https://git.kernel.org/stable/c/a3a089c241cd49b33a8cdd7fcb37cc87a086912a - https://git.kernel.org/stable/c/b05caf023b14cbed9
s://git.kernel.org/stable/c/a3a089c241cd49b33a8cdd7fcb37cc87a086912a - https://git.kernel.org/stable/c/b05caf023b14cbed9223bb5b48ecc7bffe38f632 - https://git.kernel.org/stable/c/f1b98569e81c37d7e0deada7172f8f60860c1360 - https://git.kernel.org/stable/c/fa9b6b6c953e3f6441ed6cf83b4c771dac2dae08 - https://git.kernel.org/stable/c/5314454ea3ff6fc746eaf71b9a7ceebed52888fa
CVE ID: CVE-2021-47461 State: PUBLISHED Published: 2024-05-22T06:23:22.373Z Last Updated: 2025-05-04T07:11:24.932Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: userfaultfd: fix a race between writeprotect and exit_mmap() A race is possible when a process exits, its VMAs are removed by exit_mmap() and at the same time userfaultfd_writeprotect() is called. The race was detected by KASAN on a development kernel, but it appears to be possible on vanilla kernels as well. Use mmget_not_zero() to prevent the race as done in other userfaultfd operations. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: Refe
s done in other userfaultfd operations. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/3cda4bfffd4f755645577aaa9e96a606657b4525 - https://git.kernel.org/stable/c/149958ecd0627a9f1e9c678c25c665400054cd6a - https://git.kernel.org/stable/c/cb185d5f1ebf900f4ae3bf84cee212e6dd035aca
CVE ID: CVE-2021-47462 State: PUBLISHED Published: 2024-05-22T06:23:23.034Z Last Updated: 2025-05-04T07:11:26.025Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: do not allow illegal MPOL_F_NUMA_BALANCING | MPOL_LOCAL in mbind() syzbot reported access to unitialized memory in mbind() [1] Issue came with commit bda420b98505 ("numa balancing: migrate on fault among multiple bound nodes") This commit added a new bit in MPOL_MODE_FLAGS, but only checked valid combination (MPOL_F_NUMA_BALANCING can only be used with MPOL_BIND) in do_set_mempolicy() This patch moves the check in sanitize_mpol_flags() so that it is also
ly be used with MPOL_BIND) in do_set_mempolicy() This patch moves the check in sanitize_mpol_flags() so that it is also used by mbind() [1] BUG: KMSAN: uninit-value in __mpol_equal+0x567/0x590 mm/mempolicy.c:2260 __mpol_equal+0x567/0x590 mm/mempolicy.c:2260 mpol_equal include/linux/mempolicy.h:105 [inline] vma_merge+0x4a1/0x1e60 mm/mmap.c:1190 mbind_range+0xcc8/0x1e80 mm/mempolicy.c:811 do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333 kernel_mbind mm/mempolicy.c:1483 [inline] __do_sys_mbind mm/mempolicy.c:1490 [inline] __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486 __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/ent
+0x19d/0x200 mm/mempolicy.c:1486 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Uninit was created at: slab_alloc_node mm/slub.c:3221 [inline] slab_alloc mm/slub.c:3230 [inline] kmem_cache_alloc+0x751/0xff0 mm/slub.c:3235 mpol_new mm/mempolicy.c:293 [inline] do_mbind+0x912/0x15f0 mm/mempolicy.c:1289 kernel_mbind mm/mempolicy.c:1483 [inline] __do_sys_mbind mm/mempolicy.c:1490 [inline] __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486 __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_aft
_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae ===================================================== Kernel panic - not syncing: panic_on_kmsan set ... CPU: 0 PID: 15049 Comm: syz-executor.0 Tainted: G B 5.15.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1ff/0x28e lib/dump_stack.c:106 dump_stack+0x25/0x28 lib/dump_stack.c:113 panic+0x44f/0xdeb kernel/panic.c:232 kmsan_report+0x2ee/0x300 mm/kmsan/report.c:186 __msan_warning+0xd7/0x150 mm/kmsan/instrumentation.c:208 __m
/panic.c:232 kmsan_report+0x2ee/0x300 mm/kmsan/report.c:186 __msan_warning+0xd7/0x150 mm/kmsan/instrumentation.c:208 __mpol_equal+0x567/0x590 mm/mempolicy.c:2260 mpol_equal include/linux/mempolicy.h:105 [inline] vma_merge+0x4a1/0x1e60 mm/mmap.c:1190 mbind_range+0xcc8/0x1e80 mm/mempolicy.c:811 do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333 kernel_mbind mm/mempolicy.c:1483 [inline] __do_sys_mbind mm/mempolicy.c:1490 [inline] __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486 __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Additional Analyst Notes: - CISA ADP Vul
4+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/9ee4e9ae98f1f262d6fae0d266cfdf3ba2c321d9 - https://git.kernel.org/stable/c/6d2aec9e123bb9c49cb5c7fc654f25f81e688e8c
CVE ID: CVE-2021-47463 State: PUBLISHED Published: 2024-05-22T06:23:23.688Z Last Updated: 2025-05-04T07:11:27.089Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/secretmem: fix NULL page->mapping dereference in page_is_secretmem() Check for a NULL page->mapping before dereferencing the mapping in page_is_secretmem(), as the page's mapping can be nullified while gup() is running, e.g. by reclaim or truncation. BUG: kernel NULL pointer dereference, address: 0000000000000068 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 6 PID: 4173897 Com
el mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 6 PID: 4173897 Comm: CPU 3/KVM Tainted: G W RIP: 0010:internal_get_user_pages_fast+0x621/0x9d0 Code: <48> 81 7a 68 80 08 04 bc 0f 85 21 ff ff 8 89 c7 be RSP: 0018:ffffaa90087679b0 EFLAGS: 00010046 RAX: ffffe3f37905b900 RBX: 00007f2dd561e000 RCX: ffffe3f37905b934 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffe3f37905b900 ... CR2: 0000000000000068 CR3: 00000004c5898003 CR4: 00000000001726e0 Call Trace: get_user_pages_fast_only+0x13/0x20 hva_to_pfn+0xa9/0x3e0 try_async_pf+0xa1/0x270 direct_page_fault+0x113/0xad0 kvm_mmu_page_fault+0x69/0x680 vmx_handle_exit+0xe1/0x5d0 kvm_arch_vcpu_ioctl
pf+0xa1/0x270 direct_page_fault+0x113/0xad0 kvm_mmu_page_fault+0x69/0x680 vmx_handle_exit+0xe1/0x5d0 kvm_arch_vcpu_ioctl_run+0xd81/0x1c70 kvm_vcpu_ioctl+0x267/0x670 __x64_sys_ioctl+0x83/0xa0 do_syscall_64+0x56/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/b77ba1e02345bafd703f0d407bdbd88c3be1f767 - https://git.kernel.org/stable/c/79f9bc5843142b649575f887dccdf1c07ad75c20
CVE ID: CVE-2021-47464 State: PUBLISHED Published: 2024-05-22T06:23:24.355Z Last Updated: 2025-05-04T07:11:28.220Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: audit: fix possible null-pointer dereference in audit_filter_rules Fix possible null-pointer dereference in audit_filter_rules. audit_filter_rules() error: we previously assumed 'ctx' could be null Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/d6f451f1f60c58d73038c7c3177066f8f084e2a2 - https://git.kernel.org/stable/c/16802fa4c33eb1a8efb23f1e93365190e4047d05 - https://git.kernel.org/stable/c/4e9
084e2a2 - https://git.kernel.org/stable/c/16802fa4c33eb1a8efb23f1e93365190e4047d05 - https://git.kernel.org/stable/c/4e9e46a700201b4c85081fd478c99c692a9aaa0d - https://git.kernel.org/stable/c/6e3ee990c90494561921c756481d0e2125d8b895
CVE ID: CVE-2021-47465 State: PUBLISHED Published: 2024-05-22T06:23:25.027Z Last Updated: 2025-05-04T07:11:29.563Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest() In commit 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C") kvm_start_guest() became idle_kvm_start_guest(). The old code allocated a stack frame on the emergency stack, but didn't use the frame to store anything, and also didn't store anything in its caller's frame. idle_kvm_start_guest() on the other hand is written more like a normal C function, it creates a frame on entry, and also stor