Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
c Considering the gpio_keys_irq_isr() can run in any context, e.g. it can be threaded, it seems there's no point in requesting the timer isr to run in hard irq context. Relax the hrtimer not to use the hard context. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/664e5a6f541ff226621487d1280d2ec28e86be28 - https://git.kernel.org/stable/c/a8f01e51109f77229e426b57c5d19251b462c6aa - https://git.kernel.org/stable/c/fa53beab4740c4e5fe969f218a379f9558be33dc - https://git.kernel.org/stable/c/a7b79db25846459de63ca8974268f0c41c734c4b - https://git.kernel.org/stable/c/ec8f5da79b425deef5aebacdd4fe645620cd4f0b - https://git.kernel.org/stable/c/f4a8f561d08e
https://git.kernel.org/stable/c/ec8f5da79b425deef5aebacdd4fe645620cd4f0b - https://git.kernel.org/stable/c/f4a8f561d08e39f7833d4a278ebfb12a41eef15f
CVE ID: CVE-2025-38336 State: PUBLISHED Published: 2025-07-10T08:15:07.700Z Last Updated: 2025-11-03T17:36:45.728Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330 The controller has a hardware bug that can hard hang the system when doing ATAPI DMAs without any trace of what happened. Depending on the device attached, it can also prevent the system from booting. In this case, the system hangs when reading the ATIP from optical media with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4, running
atip on an _NEC DVD_RW ND-4571A 1-01 and an Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4, running at UDMA/33. The issue can be reproduced by running the same command with a cygwin build of cdrecord on WinXP, although it requires more attempts to cause it. The hang in that case is also resolved by forcing PIO. It doesn't appear that VIA has produced any drivers for that OS, thus no known workaround exists. HDDs attached to the controller do not suffer from any DMA issues. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/67d66a5e4583fd3bcf13d6f747e571df13cbad51 - https://git.kernel.org/stable/c/0d9a48dfa934f43ac839211ae4aeba
l.org/stable/c/67d66a5e4583fd3bcf13d6f747e571df13cbad51 - https://git.kernel.org/stable/c/0d9a48dfa934f43ac839211ae4aeba34f666a9a5 - https://git.kernel.org/stable/c/7fc89c218fc96a296a2840b1e37f4e0975f7a108 - https://git.kernel.org/stable/c/8212cd92fe40aae6fe5a073bc70e758c42bb4bfc - https://git.kernel.org/stable/c/8edfed4439b107d62151ff6c075958d169da3e71 - https://git.kernel.org/stable/c/947f9304d3c876c6672b947b80c0ef51161c6d2f - https://git.kernel.org/stable/c/bb7212ee4ff086628a2c1c22336d082a87cb893d - https://git.kernel.org/stable/c/d29fc02caad7f94b62d56ee1b01c954f9c961ba7
CVE ID: CVE-2025-38337 State: PUBLISHED Published: 2025-07-10T08:15:08.396Z Last Updated: 2025-11-03T17:36:47.615Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata() Since handle->h_transaction may be a NULL pointer, so we should change it to call is_handle_aborted(handle) first before dereferencing it. And the following data-race was reported in my fuzzer: ================================================================== BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata write to 0xffff888011024104 of 4 bytes by task 10881 on c
e in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata write to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1: jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0: jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:
transaction.c:1512 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103 .... value changed: 0x00000000 -> 0x00000001 ================================================================== This issue is caused by missing data-race annotation for jh->b_modified. Therefore, the missing annotation needs to be added. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/5c1a34ff5b0bfdfd2f9343aa9b08d25df618bac5 - https://git.kernel.org/stable/
References: - https://git.kernel.org/stable/c/5c1a34ff5b0bfdfd2f9343aa9b08d25df618bac5 - https://git.kernel.org/stable/c/ec669e5bf409f16e464bfad75f0ba039a45de29a - https://git.kernel.org/stable/c/43d5e3bb5f1dcd91e30238ea0b59a5f77063f84e - https://git.kernel.org/stable/c/23361b479f2700c00960d3ae9cdc8ededa762d47 - https://git.kernel.org/stable/c/2e7c64d7a92c031d016f11c8e8cb05131ab7b75a - https://git.kernel.org/stable/c/f78b38af3540b4875147b7b884ee11a27b3dbf4c - https://git.kernel.org/stable/c/a377996d714afb8d4d5f4906336f78510039da29 - https://git.kernel.org/stable/c/af98b0157adf6504fade79b3e6cb260c4ff68e37
CVE ID: CVE-2025-38338 State: PUBLISHED Published: 2025-07-10T08:15:09.022Z Last Updated: 2025-07-28T04:19:20.008Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio() Sometimes, when a file was read while it was being truncated by another NFS client, the kernel could deadlock because folio_unlock() was called twice, and the second call would XOR back the `PG_locked` flag. Most of the time (depending on the timing of the truncation), nobody notices the problem because folio_unlock() gets called three times, which flips `PG_locked` back off: 1. vfs_read, nfs_read_folio, ..
roblem because folio_unlock() gets called three times, which flips `PG_locked` back off: 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio, nfs_return_empty_folio 2. vfs_read, nfs_read_folio, ... netfs_read_collection, netfs_unlock_abandoned_read_pages 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio, nfs_return_empty_folio The problem is that nfs_read_add_folio() is not supposed to unlock the folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is missing in nfs_return_empty_folio(). Rarely this leads to a warning in netfs_read_collection(): ------------[ cut here ]------------ R=0000031c: folio 10 is not locked WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 net
--[ cut here ]------------ R=0000031c: folio 10 is not locked WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00 [...] Workqueue: events_unbound netfs_read_collection_worker RIP: 0010:netfs_read_collection+0x7c0/0xf00 [...] Call Trace: <TASK> netfs_read_collection_worker+0x67/0x80 process_one_work+0x12e/0x2c0 worker_thread+0x295/0x3a0 Most of the time, however, processes just get stuck forever in folio_wait_bit_common(), waiting for `PG_locked` to disappear, which never happens because nobody is really holding the folio lock. References: - https://git.kernel.org/stable/c/14f5549ad163be2c018abc1bb38370fff617a243 - https://git.kernel.org/stable/c/5bf0b9eeb
: - https://git.kernel.org/stable/c/14f5549ad163be2c018abc1bb38370fff617a243 - https://git.kernel.org/stable/c/5bf0b9eeb0174686f22c2e5b8fb9f47ad25da6f5 - https://git.kernel.org/stable/c/1e93b61d3eaa14bfebcc2716ac09d43f3845d420 - https://git.kernel.org/stable/c/4c10fa44bc5f700e2ea21de2fbae520ba21f19d9
CVE ID: CVE-2025-38339 State: PUBLISHED Published: 2025-07-10T08:15:09.646Z Last Updated: 2025-07-28T04:19:21.444Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powerpc/bpf: fix JIT code size calculation of bpf trampoline arch_bpf_trampoline_size() provides JIT size of the BPF trampoline before the buffer for JIT'ing it is allocated. The total number of instructions emitted for BPF trampoline JIT code depends on where the final image is located. So, the size arrived at with the dummy pass in arch_bpf_trampoline_size() can vary from the actual size needed in arch_prepare_bpf_trampoline(). When the instructions accounted in arch
ne_size() can vary from the actual size needed in arch_prepare_bpf_trampoline(). When the instructions accounted in arch_bpf_trampoline_size() is less than the number of instructions emitted during the actual JIT compile of the trampoline, the below warning is produced: WARNING: CPU: 8 PID: 204190 at arch/powerpc/net/bpf_jit_comp.c:981 __arch_prepare_bpf_trampoline.isra.0+0xd2c/0xdcc which is: /* Make sure the trampoline generation logic doesn't overflow */ if (image && WARN_ON_ONCE(&image[ctx->idx] > (u32 *)rw_image_end - BPF_INSN_SAFETY)) { So, during the dummy pass, instead of providing some arbitrary image location, account for maximum possible instructions if and when there is a depende
ead of providing some arbitrary image location, account for maximum possible instructions if and when there is a dependency with image location for JIT'ing. References: - https://git.kernel.org/stable/c/7833deb95e05bec146414b3a2feb24f025ca27c0 - https://git.kernel.org/stable/c/59ba025948be2a92e8bc9ae1cbdaf197660bd508
CVE ID: CVE-2025-38340 State: PUBLISHED Published: 2025-07-10T08:15:10.285Z Last Updated: 2025-07-28T04:19:22.993Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Fix OOB memory read access in KUnit test KASAN reported out of bounds access - cs_dsp_mock_bin_add_name_or_info(), because the source string length was rounded up to the allocation size. References: - https://git.kernel.org/stable/c/8f4cc454a0bb45b800bc7817c09c8f72e31901f3 - https://git.kernel.org/stable/c/fe6446215bfad11cf3b446f38b28dc7708973c25
CVE ID: CVE-2025-38341 State: PUBLISHED Published: 2025-07-10T08:15:10.928Z Last Updated: 2025-07-28T04:19:24.527Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: eth: fbnic: avoid double free when failing to DMA-map FW msg The semantics are that caller of fbnic_mbx_map_msg() retains the ownership of the message on error. All existing callers dutifully free the page. References: - https://git.kernel.org/stable/c/670179265ad787b9dd8e701601914618b8927755 - https://git.kernel.org/stable/c/0a211e23852019ef55c70094524e87a944accbb5 - https://git.kernel.org/stable/c/5bd1bafd4474ee26f504b41aba11f3e2a1175b88
CVE ID: CVE-2025-38342 State: PUBLISHED Published: 2025-07-10T08:15:11.561Z Last Updated: 2025-11-03T17:36:49.489Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: software node: Correct a OOB check in software_node_get_reference_args() software_node_get_reference_args() wants to get @index-th element, so the property value requires at least '(index + 1) * sizeof(*ref)' bytes but that can not be guaranteed by current OOB check, and may cause OOB for malformed property. Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/st
izeof(*ref) > prop->length)'. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/142acd739eb6f08c148a96ae8309256f1422ff4b - https://git.kernel.org/stable/c/56ce76e8d406cc72b89aee7931df5cf3f18db49d - https://git.kernel.org/stable/c/9324127b07dde8529222dc19233aa57ec810856c - https://git.kernel.org/stable/c/f9397cf7bfb680799fb8c7f717c8f756384c3280 - https://git.kernel.org/stable/c/4b3383110b6df48e0ba5936af2cb68d5eb6bd43b - https://git.kernel.org/stable/c/7af18e42bdefe1dba5bcb32555a4d524fd504939 - https://git.kernel.org/stable/c/31e4e12e0e9609850cefd4b2e1adf782f56337d6
CVE ID: CVE-2025-38343 State: PUBLISHED Published: 2025-07-10T08:15:12.154Z Last Updated: 2025-07-28T04:19:27.588Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: drop fragments with multicast or broadcast RA IEEE 802.11 fragmentation can only be applied to unicast frames. Therefore, drop fragments with multicast or broadcast RA. This patch addresses vulnerabilities such as CVE-2020-26145. References: - https://git.kernel.org/stable/c/24900688ee47071aa6a61e78473999b5b80f0423 - https://git.kernel.org/stable/c/d4b93f9c2f666011dcf810050ef60a6b8d06f186 - https://git.kernel.org/stable/c/5fd5b8132b5de08c99eea003f77
rnel.org/stable/c/d4b93f9c2f666011dcf810050ef60a6b8d06f186 - https://git.kernel.org/stable/c/5fd5b8132b5de08c99eea003f7715ff2e361b007 - https://git.kernel.org/stable/c/80fda1cd7b0a1edd0849dc71403a070d0922118d
CVE ID: CVE-2025-38344 State: PUBLISHED Published: 2025-07-10T08:15:12.791Z Last Updated: 2025-11-03T17:36:51.372Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ACPICA: fix acpi parse and parseext cache leaks ACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5 I'm Seunghun Han, and I work for National Security Research Institute of South Korea. I have been doing a research on ACPI and found an ACPI cache leak in ACPI early abort cases. Boot log of ACPI cache leak is as follows: [ 0.352414] ACPI: Added _OSI(Module Device) [ 0.353182] ACPI: Added _OSI(Processor Device) [ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.353
(Module Device) [ 0.353182] ACPI: Added _OSI(Processor Device) [ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.353182] ACPI: Added _OSI(Processor Aggregator Device) [ 0.356028] ACPI: Unable to start the ACPI Interpreter [ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects [ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #10 [ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.361873] Call Trace: [ 0.362243] ? dump_stack+0x5c/0x81 [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27
362243] ? dump_stack+0x5c/0x81 [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27 [ 0.363296] ? acpi_os_delete_cache+0xa/0x10 [ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.364000] ? acpi_terminate+0xa/0x14 [ 0.364000] ? acpi_init+0x2af/0x34f [ 0.364000] ? __class_create+0x4c/0x80 [ 0.364000] ? video_setup+0x7f/0x7f [ 0.364000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.364000] ? do_one_initcall+0x4e/0x1a0 [ 0.364000] ? kernel_init_freeable+0x189/0x20a [ 0.364000] ? rest_init+0xc0/0xc0 [ 0.364000] ? kernel_init+0xa/0x100 [ 0.364000] ? ret_from_fork+0x25/0x30 I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were
_from_fork+0x25/0x30 I analyzed this memory leak in detail. I found that “Acpi-State” cache and “Acpi-Parse” cache were merged because the size of cache objects was same slab cache size. I finally found “Acpi-Parse” cache and “Acpi-parse_ext” cache were leaked using SLAB_NEVER_MERGE flag in kmem_cache_create() function. Real ACPI cache leak point is as follows: [ 0.360101] ACPI: Added _OSI(Module Device) [ 0.360101] ACPI: Added _OSI(Processor Device) [ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.361043] ACPI: Added _OSI(Processor Aggregator Device) [ 0.364016] ACPI: Unable to start the ACPI Interpreter [ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.368
Unable to start the ACPI Interpreter [ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) [ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects [ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.372000] Call Trace: [ 0.372000] ? dump_stack+0x5c/0x81 [ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? acpi_os_delete_cache+0xa/0x10 [ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b [ 0.372000] ? acpi_terminate+0xa/0x14 [ 0.372000] ? acpi_init+0x2af/0x34f [ 0.372000] ? __class_cr
lete_caches+0x56/0x7b [ 0.372000] ? acpi_terminate+0xa/0x14 [ 0.372000] ? acpi_init+0x2af/0x34f [ 0.372000] ? __class_create+0x4c/0x80 [ 0.372000] ? video_setup+0x7f/0x7f [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? do_one_initcall+0x4e/0x1a0 [ 0.372000] ? kernel_init_freeable+0x189/0x20a [ 0.372000] ? rest_init+0xc0/0xc0 [ 0.372000] ? kernel_init+0xa/0x100 [ 0.372000] ? ret_from_fork+0x25/0x30 [ 0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.12.0-rc4-next-20170608+ #8 [ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.392000] Call Trace: [ 0.392000
57] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.392000] Call Trace: [ 0.392000] ? dump_stack+0x5c/0x81 [ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? acpi_os_delete_cache+0xa/0x10 [ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.392000] ? acpi_terminate+0xa/0x14 [ 0.392000] ? acpi_init+0x2af/0x3 ---truncated--- Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/1e0e629e88b1f7751ce69bf70cda6d1598d45271 - https://git.kernel.org/stable/c/41afebc9a0762aafc35d2df88f4e1b798155a940 - https://git.kernel.org/stable/c/960236150cd3f08e13b397dd5ae4ccf7a2986c00
le/c/41afebc9a0762aafc35d2df88f4e1b798155a940 - https://git.kernel.org/stable/c/960236150cd3f08e13b397dd5ae4ccf7a2986c00 - https://git.kernel.org/stable/c/0a119fdaed67566aa3e0b5222dced4d08bbce463 - https://git.kernel.org/stable/c/1fee4324b5660de080cefc3fc91c371543bdb8f6 - https://git.kernel.org/stable/c/198c2dab022e5e94a99fff267b669d693bc7bb49 - https://git.kernel.org/stable/c/3e0c59180ec83bdec43b3d3482cff23d86d380d0 - https://git.kernel.org/stable/c/bed18f0bdcd6737a938264a59d67923688696fc4
CVE ID: CVE-2025-38345 State: PUBLISHED Published: 2025-07-10T08:15:13.652Z Last Updated: 2025-11-03T17:36:53.250Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ACPICA: fix acpi operand cache leak in dswstate.c ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732 I found an ACPI cache leak in ACPI early termination and boot continuing case. When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI
em_cache_destroy() reports Acpi-Operand cache leak. Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cach
] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x
0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and
> ... Continue to boot and log is omitted ... I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_ delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push() function uses walk_state->operand_index for start position of the top, but acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it. Therefore, this causes acpi operand memory leak. This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Additional Analyst Notes: - CVE Program Container: Re
ralize kernel ASLR. I made a patch to fix ACPI operand cache leak. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/4fa430a8bca708c7776f6b9d001257f48b19a5b7 - https://git.kernel.org/stable/c/1c0d9115a001979cb446ba5e8331dd1d29a10bbf - https://git.kernel.org/stable/c/5a68893b594ee6ce0efce5f74c07e64e9dd0c2c4 - https://git.kernel.org/stable/c/64c4bcf0308dd1d752ef31d560040b8725e29984 - https://git.kernel.org/stable/c/755a8006b76792922ff7b1c9674d8897a476b5d7 - https://git.kernel.org/stable/c/76d37168155880f2b04a0aad92ceb0f9d799950e - https://git.kernel.org/stable/c/e0783910ca4368b01466bc8dcdcc13c3e0b7db53 - https://git.kernel.org/stable/c/156fd20a41e
- https://git.kernel.org/stable/c/e0783910ca4368b01466bc8dcdcc13c3e0b7db53 - https://git.kernel.org/stable/c/156fd20a41e776bbf334bd5e45c4f78dfc90ce1c
CVE ID: CVE-2025-38346 State: PUBLISHED Published: 2025-07-10T08:15:14.290Z Last Updated: 2025-11-03T17:36:55.187Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix UAF when lookup kallsym after ftrace disabled The following issue happens with a buggy module: BUG: unable to handle page fault for address: ffffffffc05d0218 PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0 Oops: Oops: 0000 [#1] SMP KASAN PTI Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS RIP: 0010:sized_strscpy+0x81/0x2f0 RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246 RAX: 0000000000000000
+ PIIX, 1996), BIOS RIP: 0010:sized_strscpy+0x81/0x2f0 RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000 RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2d RBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68 R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038 R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeff FS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 000000000