Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
llocating `new_smi->si_sm`, the variable wouldn't be freed in the error handling afterwards since `shutdown_smi()` hadn't been registered yet. Fix it by adding a `kfree()` in the error handling path in `try_smi_init()`. References: - https://git.kernel.org/stable/c/b9bc8fbb2d416ce87f0342478dc9fcfd79f2c65f - https://git.kernel.org/stable/c/f53ab5a2bf20fed59a2f7542d3453228b8056358 - https://git.kernel.org/stable/c/5c5f02e16b919c8cb6024dc3778c8d8f1fb1f26b - https://git.kernel.org/stable/c/cbb7d8a4b4beb3061b3a1847a742983a01dca381 - https://git.kernel.org/stable/c/09cb2a71b2e982015fe0464f28da1ab42b8e6375 - https://git.kernel.org/stable/c/1bfcfea0fae0d0a6c6ff5543e6d704b3807b83ce - https://git.kern
015fe0464f28da1ab42b8e6375 - https://git.kernel.org/stable/c/1bfcfea0fae0d0a6c6ff5543e6d704b3807b83ce - https://git.kernel.org/stable/c/7291af9a738d936c2d6869d030711dceb68404d0 - https://git.kernel.org/stable/c/6cf1a126de2992b4efe1c3c4d398f8de4aed6e3f
CVE ID: CVE-2023-53612 State: PUBLISHED Published: 2025-10-04T15:44:20.297Z Last Updated: 2025-10-04T15:44:20.297Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Simplify platform device handling Coretemp's platform driver is unconventional. All the real work is done globally by the initcall and CPU hotplug notifiers, while the "driver" effectively just wraps an allocation and the registration of the hwmon interface in a long-winded round-trip through the driver core. The whole logic of dynamically creating and destroying platform devices to bring the interfaces up and down is error prone, since it assumes pla
ically creating and destroying platform devices to bring the interfaces up and down is error prone, since it assumes platform_device_add() will synchronously bind the driver and set drvdata before it returns, thus results in a NULL dereference if drivers_autoprobe is turned off for the platform bus. Furthermore, the unusual approach of doing that from within a CPU hotplug notifier, already commented in the code that it deadlocks suspend, also causes lockdep issues for other drivers or subsystems which may want to legitimately register a CPU hotplug notifier from a platform bus notifier. All of these issues can be solved by ripping this unusual behaviour out completely, simply tying the platf
bus notifier. All of these issues can be solved by ripping this unusual behaviour out completely, simply tying the platform devices to the lifetime of the module itself, and directly managing the hwmon interfaces from the hotplug notifiers. There is a slight user-visible change in that /sys/bus/platform/drivers/coretemp will no longer appear, and /sys/devices/platform/coretemp.n will remain present if package n is hotplugged off, but hwmon users should really only be looking for the presence of the hwmon interfaces, whose behaviour remains unchanged. References: - https://git.kernel.org/stable/c/4000384684f612b3645a944f6acde0e65ac370b8 - https://git.kernel.org/stable/c/5735878a7b7db7e9ce731c
it.kernel.org/stable/c/4000384684f612b3645a944f6acde0e65ac370b8 - https://git.kernel.org/stable/c/5735878a7b7db7e9ce731cb36cec298a9de67549 - https://git.kernel.org/stable/c/52ea47a0ddfbc5fe05e873d3f5a59db4ba3e03fe - https://git.kernel.org/stable/c/8fcdbc4bc01365f4b10fed7db544a3149e3054fd - https://git.kernel.org/stable/c/c57a8d14d7880521150ee801d53a0a64fdffd9c8 - https://git.kernel.org/stable/c/6d03bbff456befeccdd4d663177c4d6c75d0c4ff
CVE ID: CVE-2023-53613 State: PUBLISHED Published: 2025-10-04T15:44:20.998Z Last Updated: 2025-10-04T15:44:20.998Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dax: Fix dax_mapping_release() use after free A CONFIG_DEBUG_KOBJECT_RELEASE test of removing a device-dax region provider (like modprobe -r dax_hmem) yields: kobject: 'mapping0' (ffff93eb460e8800): kobject_release, parent 0000000000000000 (delayed 2000) [..] DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 23 PID: 282 at kernel/locking/lockdep.c:232 __lock_acquire+0x9fc/0x2260 [..] RIP: 0010:__lock_acquire+0x9fc/0x2260 [..] Call Trace: <TASK> [..] lock_acquire+0xd4/0x2c0 ? ida_fr
re+0x9fc/0x2260 [..] RIP: 0010:__lock_acquire+0x9fc/0x2260 [..] Call Trace: <TASK> [..] lock_acquire+0xd4/0x2c0 ? ida_free+0x62/0x130 _raw_spin_lock_irqsave+0x47/0x70 ? ida_free+0x62/0x130 ida_free+0x62/0x130 dax_mapping_release+0x1f/0x30 device_release+0x36/0x90 kobject_delayed_cleanup+0x46/0x150 Due to attempting ida_free() on an ida object that has already been freed. Devices typically only hold a reference on their parent while registered. If a child needs a parent object to complete its release it needs to hold a reference that it drops from its release callback. Arrange for a dax_mapping to pin its parent dev_dax instance until dax_mapping_release(). References: - https://git.kernel.or
ge for a dax_mapping to pin its parent dev_dax instance until dax_mapping_release(). References: - https://git.kernel.org/stable/c/94a85474f5e3e518bdbf8c9f51cb343d734a04f7 - https://git.kernel.org/stable/c/9c2f993b6ca903c030d58451b5bf9ea27d0d17fa - https://git.kernel.org/stable/c/03859868ab82d57bfdd0cea1bf31f9319a5dded0 - https://git.kernel.org/stable/c/f76db6781d76d8464ec2faa9752cc3fb2e4f6923 - https://git.kernel.org/stable/c/7310b84821f043dcf77d5e6aa0ad55dc1e10a11d - https://git.kernel.org/stable/c/6d24b170a9db0456f577b1ab01226a2254c016a8
CVE ID: CVE-2023-53614 State: PUBLISHED Published: 2025-10-04T15:44:21.671Z Last Updated: 2025-10-04T15:44:21.671Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/ksm: fix race with VMA iteration and mm_struct teardown exit_mmap() will tear down the VMAs and maple tree with the mmap_lock held in write mode. Ensure that the maple tree is still valid by checking ksm_test_exit() after taking the mmap_lock in read mode, but before the for_each_vma() iterator dereferences a destroyed maple tree. Since the maple tree is destroyed, the flags telling lockdep to check an external lock has been cleared. Skip the for_each_vma() iterator
ree is destroyed, the flags telling lockdep to check an external lock has been cleared. Skip the for_each_vma() iterator to avoid dereferencing a maple tree without the external lock flag, which would create a lockdep warning. References: - https://git.kernel.org/stable/c/286b0cab31bac29960e5684f6fb331d42f03b363 - https://git.kernel.org/stable/c/b4f664ffd8f78c05a1fd542a28bc5a11e994c014 - https://git.kernel.org/stable/c/6db504ce55bdbc575723938fc480713c9183f6a2
CVE ID: CVE-2023-53615 State: PUBLISHED Published: 2025-10-04T15:44:22.376Z Last Updated: 2025-10-04T15:44:22.376Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix deletion race condition System crash when using debug kernel due to link list corruption. The cause of the link list corruption is due to session deletion was allowed to queue up twice. Here's the internal trace that show the same port was allowed to double queue for deletion on different cpu. 20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1 20808683957 027 qla2xxx [0000:1
e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1 20808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1 Move the clearing/setting of deleted flag lock. References: - https://git.kernel.org/stable/c/a4628a5b98e4c6d905e1f7638242612d7db7d9c2 - https://git.kernel.org/stable/c/4d7da12483e98c451a51bd294a3d3494f0aee5eb - https://git.kernel.org/stable/c/f1ea164be545629bf442c22f508ad9e7b94ac100 - https://git.kernel.org/stable/c/cd06c45b326e44f0d21dc1b3fa23e71f46847e28 - https://git.kernel.org/stable/c/b05017cb4ff75eea783583f3d400059507510ab1 - https://git.kernel.org/stable/c/6dfe4344c168c6
ttps://git.kernel.org/stable/c/b05017cb4ff75eea783583f3d400059507510ab1 - https://git.kernel.org/stable/c/6dfe4344c168c6ca20fe7640649aacfcefcccb26
CVE ID: CVE-2023-53616 State: PUBLISHED Published: 2025-10-04T15:44:23.056Z Last Updated: 2025-10-04T15:44:23.056Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: jfs: fix invalid free of JFS_IP(ipimap)->i_imap in diUnmount syzbot found an invalid-free in diUnmount: BUG: KASAN: double-free in slab_free mm/slub.c:3661 [inline] BUG: KASAN: double-free in __kmem_cache_free+0x71/0x110 mm/slub.c:3674 Free of addr ffff88806f410000 by task syz-executor131/3632 CPU: 0 PID: 3632 Comm: syz-executor131 Not tainted 6.1.0-rc7-syzkaller-00012-gca57f02295f1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26
c7-syzkaller-00012-gca57f02295f1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report_invalid_free+0xac/0xd0 mm/kasan/report.c:460 ____kasan_slab_free+0xfb/0x120 kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1724 [inline] slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1750 slab_free mm/slub.c:3661 [inline] __kmem_cache_free+0x71/0x110 mm/slub.c:3674 diUnmount+0xef/0x100 fs/jfs/jfs_imap.c:195 jfs_umou
mm/slub.c:3661 [inline] __kmem_cache_free+0x71/0x110 mm/slub.c:3674 diUnmount+0xef/0x100 fs/jfs/jfs_imap.c:195 jfs_umount+0x108/0x370 fs/jfs/jfs_umount.c:63 jfs_put_super+0x86/0x190 fs/jfs/super.c:194 generic_shutdown_super+0x130/0x310 fs/super.c:492 kill_block_super+0x79/0xd0 fs/super.c:1428 deactivate_locked_super+0xa7/0xf0 fs/super.c:332 cleanup_mnt+0x494/0x520 fs/namespace.c:1186 task_work_run+0x243/0x300 kernel/task_work.c:179 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x664/0x2070 kernel/exit.c:820 do_group_exit+0x1fd/0x2b0 kernel/exit.c:950 __do_sys_exit_group kernel/exit.c:961 [inline] __se_sys_exit_group kernel/exit.c:959 [inline] __x64_sys_exit_group+0x3b/0x40 ke
s_exit_group kernel/exit.c:961 [inline] __se_sys_exit_group kernel/exit.c:959 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:959 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] JFS_IP(ipimap)->i_imap is not setting to NULL after free in diUnmount. If jfs_remount() free JFS_IP(ipimap)->i_imap but then failed at diMount(). JFS_IP(ipimap)->i_imap will be freed once again. Fix this problem by setting JFS_IP(ipimap)->i_imap to NULL after free. References: - https://git.kernel.org/stable/c/c3c0f0ddd851b3fa3e9d3450bbcd561f4f850469 - https://git.kernel.org/stable/c/114ea3cb13ab25f7178cb60283ad
nel.org/stable/c/c3c0f0ddd851b3fa3e9d3450bbcd561f4f850469 - https://git.kernel.org/stable/c/114ea3cb13ab25f7178cb60283adb93d2f96dad7 - https://git.kernel.org/stable/c/5873df0195124be2f357de11bfd473ead4f90ed8 - https://git.kernel.org/stable/c/756747d4b439e3e1159282ae89f17eefebbe9b25 - https://git.kernel.org/stable/c/ef7311101ca43dd73b45bca7a30ac72d9535ff87 - https://git.kernel.org/stable/c/4de3a603010e0ca334487de24c6aab0777b7f808 - https://git.kernel.org/stable/c/88484bde6f12126616b38e43b6c00edcd941f615 - https://git.kernel.org/stable/c/6e2bda2c192d0244b5a78b787ef20aa10cb319b7
CVE ID: CVE-2023-53617 State: PUBLISHED Published: 2025-10-07T15:19:24.618Z Last Updated: 2025-10-07T15:19:24.618Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: soc: aspeed: socinfo: Add kfree for kstrdup Add kfree() in the later error handling in order to avoid memory leak. References: - https://git.kernel.org/stable/c/dfb9676ed25be25ca7cd198d0f0e093b76b7bc7f - https://git.kernel.org/stable/c/b662856b71343d9e731c1cd4bbe54758c7791abb - https://git.kernel.org/stable/c/d9a5ad4477d2a11e9b03f00c52694451e9332228 - https://git.kernel.org/stable/c/6e6d847a8ce18ab2fbec4f579f682486a82d2c6b
CVE ID: CVE-2023-53618 State: PUBLISHED Published: 2025-10-07T15:19:25.303Z Last Updated: 2025-10-07T15:19:25.303Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: reject invalid reloc tree root keys with stack dump [BUG] Syzbot reported a crash that an ASSERT() got triggered inside prepare_to_merge(). That ASSERT() makes sure the reloc tree is properly pointed back by its subvolume tree. [CAUSE] After more debugging output, it turns out we had an invalid reloc tree: BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17 Note the above root key is (TREE_RELOC_OB
mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17 Note the above root key is (TREE_RELOC_OBJECTID, ROOT_ITEM, QUOTA_TREE_OBJECTID), meaning it's a reloc tree for quota tree. But reloc trees can only exist for subvolumes, as for non-subvolume trees, we just COW the involved tree block, no need to create a reloc tree since those tree blocks won't be shared with other trees. Only subvolumes tree can share tree blocks with other trees (thus they have BTRFS_ROOT_SHAREABLE flag). Thus this new debug output proves my previous assumption that corrupted on-disk data can trigger that ASSERT(). [FIX] Besides the dedicated fix and the graceful exit, also let tree-checker to
on-disk data can trigger that ASSERT(). [FIX] Besides the dedicated fix and the graceful exit, also let tree-checker to check such root keys, to make sure reloc trees can only exist for subvolumes. References: - https://git.kernel.org/stable/c/314135b7bae9618a317874ae195272682cf2d5d4 - https://git.kernel.org/stable/c/3ae93b316ca4b8b3c33798ef1d210355f2fb9318 - https://git.kernel.org/stable/c/84256e00eeca73c529fc6196e478cc89b8098157 - https://git.kernel.org/stable/c/6ebcd021c92b8e4b904552e4d87283032100796d
CVE ID: CVE-2023-53619 State: PUBLISHED Published: 2025-10-07T15:19:26.003Z Last Updated: 2025-10-07T15:19:26.003Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: Avoid nf_ct_helper_hash uses after free If nf_conntrack_init_start() fails (for example due to a register_nf_conntrack_bpf() failure), the nf_conntrack_helper_fini() clean-up path frees the nf_ct_helper_hash map. When built with NF_CONNTRACK=y, further netfilter modules (e.g: netfilter_conntrack_ftp) can still be loaded and call nf_conntrack_helpers_register(), independently of whether nf_conntrack initialized correctly. This accesses the nf_ct_he
nf_conntrack_helpers_register(), independently of whether nf_conntrack initialized correctly. This accesses the nf_ct_helper_hash dangling pointer and causes a uaf, possibly leading to random memory corruption. This patch guards nf_conntrack_helper_register() from accessing a freed or uninitialized nf_ct_helper_hash pointer and fixes possible uses-after-free when loading a conntrack module. References: - https://git.kernel.org/stable/c/4ee69c91cb8f9ca144bc0861969e5a1a3c6152a7 - https://git.kernel.org/stable/c/00716f25f9697d02a0d9bd622575c7c7321ba3d0 - https://git.kernel.org/stable/c/61c7a5256543ae7d24cd9d21853d514c8632e1e9 - https://git.kernel.org/stable/c/8289d422f5e484efe4a565fe18e862ecd62
/stable/c/61c7a5256543ae7d24cd9d21853d514c8632e1e9 - https://git.kernel.org/stable/c/8289d422f5e484efe4a565fe18e862ecd621c175 - https://git.kernel.org/stable/c/6f03ce2f1abcb9f9d0511e3659ca6eb60e39f566 - https://git.kernel.org/stable/c/05561f822f27b9fa88fa5504ddec34bf38833034 - https://git.kernel.org/stable/c/fce5cc7cbd4b92f979bf02c9ec5fb69aaeba92d7 - https://git.kernel.org/stable/c/6eef7a2b933885a17679eb8ed0796ddf0ee5309b
CVE ID: CVE-2023-53620 State: PUBLISHED Published: 2025-10-07T15:19:26.686Z Last Updated: 2025-10-07T15:19:26.686Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: md: fix soft lockup in status_resync status_resync() will calculate 'curr_resync - recovery_active' to show user a progress bar like following: [============>........] resync = 61.4% 'curr_resync' and 'recovery_active' is updated in md_do_sync(), and status_resync() can read them concurrently, hence it's possible that 'curr_resync - recovery_active' can overflow to a huge number. In this case status_resync() will be stuck in the loop to print a large amount of '=', whi
an overflow to a huge number. In this case status_resync() will be stuck in the loop to print a large amount of '=', which will end up soft lockup. Fix the problem by setting 'resync' to MD_RESYNC_ACTIVE in this case, this way resync in progress will be reported to user. References: - https://git.kernel.org/stable/c/b4acb6c3ede88d6b7d33742a09e63cfce5e7fb69 - https://git.kernel.org/stable/c/23309704e90859af2662bedc44101e6d1d2ece7e - https://git.kernel.org/stable/c/6efddf1e32e2a264694766ca485a4f5e04ee82a7
CVE ID: CVE-2023-53621 State: PUBLISHED Published: 2025-10-07T15:19:27.372Z Last Updated: 2025-10-07T15:19:27.372Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: memcontrol: ensure memcg acquired by id is properly set up In the eviction recency check, we attempt to retrieve the memcg to which the folio belonged when it was evicted, by the memcg id stored in the shadow entry. However, there is a chance that the retrieved memcg is not the original memcg that has been killed, but a new one which happens to have the same id. This is a somewhat unfortunate, but acceptable and rare inaccuracy in the heuristics. However, if we retriev
he same id. This is a somewhat unfortunate, but acceptable and rare inaccuracy in the heuristics. However, if we retrieve this new memcg between its allocation and when it is properly attached to the memcg hierarchy, we could run into the following NULL pointer exception during the memcg hierarchy traversal done in mem_cgroup_get_nr_swap_pages(): [ 155757.793456] BUG: kernel NULL pointer dereference, address: 00000000000000c0 [ 155757.807568] #PF: supervisor read access in kernel mode [ 155757.818024] #PF: error_code(0x0000) - not-present page [ 155757.828482] PGD 401f77067 P4D 401f77067 PUD 401f76067 PMD 0 [ 155757.839985] Oops: 0000 [#1] SMP [ 155757.887870] RIP: 0010:mem_cgroup_get_nr_swa
P4D 401f77067 PUD 401f76067 PMD 0 [ 155757.839985] Oops: 0000 [#1] SMP [ 155757.887870] RIP: 0010:mem_cgroup_get_nr_swap_pages+0x3d/0xb0 [ 155757.899377] Code: 29 19 4a 02 48 39 f9 74 63 48 8b 97 c0 00 00 00 48 8b b7 58 02 00 00 48 2b b7 c0 01 00 00 48 39 f0 48 0f 4d c6 48 39 d1 74 42 <48> 8b b2 c0 00 00 00 48 8b ba 58 02 00 00 48 2b ba c0 01 00 00 48 [ 155757.937125] RSP: 0018:ffffc9002ecdfbc8 EFLAGS: 00010286 [ 155757.947755] RAX: 00000000003a3b1c RBX: 000007ffffffffff RCX: ffff888280183000 [ 155757.962202] RDX: 0000000000000000 RSI: 0007ffffffffffff RDI: ffff888bbc2d1000 [ 155757.976648] RBP: 0000000000000001 R08: 000000000000000b R09: ffff888ad9cedba0 [ 155757.991094] R10: ffffea0039c07
0 [ 155757.976648] RBP: 0000000000000001 R08: 000000000000000b R09: ffff888ad9cedba0 [ 155757.991094] R10: ffffea0039c07900 R11: 0000000000000010 R12: ffff888b23a7b000 [ 155758.005540] R13: 0000000000000000 R14: ffff888bbc2d1000 R15: 000007ffffc71354 [ 155758.019991] FS: 00007f6234c68640(0000) GS:ffff88903f9c0000(0000) knlGS:0000000000000000 [ 155758.036356] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 155758.048023] CR2: 00000000000000c0 CR3: 0000000a83eb8004 CR4: 00000000007706e0 [ 155758.062473] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 155758.076924] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 155758.091376] PKRU: 55555554 [ 155758.
5758.076924] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 155758.091376] PKRU: 55555554 [ 155758.096957] Call Trace: [ 155758.102016] <TASK> [ 155758.106502] ? __die+0x78/0xc0 [ 155758.112793] ? page_fault_oops+0x286/0x380 [ 155758.121175] ? exc_page_fault+0x5d/0x110 [ 155758.129209] ? asm_exc_page_fault+0x22/0x30 [ 155758.137763] ? mem_cgroup_get_nr_swap_pages+0x3d/0xb0 [ 155758.148060] workingset_test_recent+0xda/0x1b0 [ 155758.157133] workingset_refault+0xca/0x1e0 [ 155758.165508] filemap_add_folio+0x4d/0x70 [ 155758.173538] page_cache_ra_unbounded+0xed/0x190 [ 155758.182919] page_cache_sync_ra+0xd6/0x1e0 [ 155758.191738] filemap_read+0x68d/0xdf0 [ 155758.199495] ?
+0xed/0x190 [ 155758.182919] page_cache_sync_ra+0xd6/0x1e0 [ 155758.191738] filemap_read+0x68d/0xdf0 [ 155758.199495] ? mlx5e_napi_poll+0x123/0x940 [ 155758.207981] ? __napi_schedule+0x55/0x90 [ 155758.216095] __x64_sys_pread64+0x1d6/0x2c0 [ 155758.224601] do_syscall_64+0x3d/0x80 [ 155758.232058] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 155758.242473] RIP: 0033:0x7f62c29153b5 [ 155758.249938] Code: e8 48 89 75 f0 89 7d f8 48 89 4d e0 e8 b4 e6 f7 ff 41 89 c0 4c 8b 55 e0 48 8b 55 e8 48 8b 75 f0 8b 7d f8 b8 11 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 45 f8 e8 e7 e6 f7 ff 48 8b [ 155758.288005] RSP: 002b:00007f6234c5ffd0 EFLAGS: 00000293 ORIG_RAX: 0000000000000011 [ 155758.30347
e7 e6 f7 ff 48 8b [ 155758.288005] RSP: 002b:00007f6234c5ffd0 EFLAGS: 00000293 ORIG_RAX: 0000000000000011 [ 155758.303474] RAX: ffffffffffffffda RBX: 00007f628c4e70c0 RCX: 00007f62c29153b5 [ 155758.318075] RDX: 000000000003c041 RSI: 00007f61d2986000 RDI: 0000000000000076 [ 155758.332678] RBP: 00007f6234c5fff0 R08: 0000000000000000 R09: 0000000064d5230c [ 155758.347452] R10: 000000000027d450 R11: 0000000000000293 R12: 000000000003c041 [ 155758.362044] R13: 00007f61d2986000 R14: 00007f629e11b060 R15: 000000000027d450 [ 155758.376661] </TASK> This patch fixes the issue by moving the memcg's id publication from the alloc stage to ---truncated--- References: - https://git.kernel.org/stable/c/b9d3
ng the memcg's id publication from the alloc stage to ---truncated--- References: - https://git.kernel.org/stable/c/b9d30c38ee859d833a51131b5b4b864c7a6219d0 - https://git.kernel.org/stable/c/6f0df8e16eb543167f2929cb756e695709a3551d
CVE ID: CVE-2023-53622 State: PUBLISHED Published: 2025-10-07T15:19:28.146Z Last Updated: 2025-10-07T15:19:28.146Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix possible data races in gfs2_show_options() Some fields such as gt_logd_secs of the struct gfs2_tune are accessed without holding the lock gt_spin in gfs2_show_options(): val = sdp->sd_tune.gt_logd_secs; if (val != 30) seq_printf(s, ",commit=%d", val); And thus can cause data races when gfs2_show_options() and other functions such as gfs2_reconfigure() are concurrently executed: spin_lock(&gt->gt_spin); gt->gt_logd_secs = newargs->ar_commit; To fix these possi
onfigure() are concurrently executed: spin_lock(&gt->gt_spin); gt->gt_logd_secs = newargs->ar_commit; To fix these possible data races, the lock sdp->sd_tune.gt_spin is acquired before accessing the fields of gfs2_tune and released after these accesses. Further changes by Andreas: - Don't hold the spin lock over the seq_printf operations. References: - https://git.kernel.org/stable/c/7e5bbeb7eb813bb2568e1d5d02587df943272e57 - https://git.kernel.org/stable/c/235a5ae73cea29109a3e06f100493f17857e6a93 - https://git.kernel.org/stable/c/b4a7ab57effbed42624842f2ab2a49b177c21a47 - https://git.kernel.org/stable/c/7c5b2649f6a37d45bfb7abf34c9b71d08677139f - https://git.kernel.org/stable/c/85e888150075c
https://git.kernel.org/stable/c/7c5b2649f6a37d45bfb7abf34c9b71d08677139f - https://git.kernel.org/stable/c/85e888150075cb221270b64bf772341fc6bd11d9 - https://git.kernel.org/stable/c/a4f71523ed2123d63b431cc0cea4e9f363a0f054 - https://git.kernel.org/stable/c/42077d4de49e4d9c773c97c42d5383b4899a8f9d - https://git.kernel.org/stable/c/6fa0a72cbbe45db4ed967a51f9e6f4e3afe61d20