Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
0] out_of_line_wait_on_bit+0x114/0x198 [ 16.945824][ C0] __sync_dirty_buffer+0x1f8/0x2e8 [ 16.945853][ C0] __f2fs_commit_super+0x140/0x1f4 [ 16.945881][ C0] f2fs_commit_super+0x110/0x28c [ 16.945898][ C0] f2fs_handle_error+0x1f4/0x2f4 [ 16.945917][ C0] f2fs_decompress_cluster+0xc4/0x450 [ 16.945942][ C0] f2fs_end_read_compressed_page+0xc0/0xfc [ 16.945959][ C0] f2fs_handle_step_decompress+0x118/0x1cc [ 16.945978][ C0] f2fs_read_end_io+0x168/0x2b0 [ 16.945993][ C0] bio_endio+0x25c/0x2c8 [ 16.946015][ C0] dm_io_dec_pending+0x3e8/0x57c [ 16.946052][ C0] clone_endio+0x134/0x254 [ 16.946069][ C0] bio_endio+0x25c/0x2c8 [ 16.946084][ C0] blk_update_request+0x1d4/0x478 [ 16.946103][ C0] scsi_end_req
[ 16.946069][ C0] bio_endio+0x25c/0x2c8 [ 16.946084][ C0] blk_update_request+0x1d4/0x478 [ 16.946103][ C0] scsi_end_request+0x38/0x4cc [ 16.946129][ C0] scsi_io_completion+0x94/0x184 [ 16.946147][ C0] scsi_finish_command+0xe8/0x154 [ 16.946164][ C0] scsi_complete+0x90/0x1d8 [ 16.946181][ C0] blk_done_softirq+0xa4/0x11c [ 16.946198][ C0] _stext+0x184/0x614 [ 16.946214][ C0] __irq_exit_rcu+0x78/0x144 [ 16.946234][ C0] handle_domain_irq+0xd4/0x154 [ 16.946260][ C0] gic_handle_irq.33881+0x5c/0x27c [ 16.946281][ C0] call_on_irq_stack+0x40/0x70 [ 16.946298][ C0] do_interrupt_handler+0x48/0xa4 [ 16.946313][ C0] el1_interrupt+0x38/0x68 [ 16.946346][ C0] el1h_64_irq_handler+0x20/0x30 [ 16.946362][ C
dler+0x48/0xa4 [ 16.946313][ C0] el1_interrupt+0x38/0x68 [ 16.946346][ C0] el1h_64_irq_handler+0x20/0x30 [ 16.946362][ C0] el1h_64_irq+0x78/0x7c [ 16.946377][ C0] finish_task_switch+0xc8/0x3d8 [ 16.946394][ C0] __schedule+0x600/0xbdc [ 16.946408][ C0] preempt_schedule_common+0x34/0x5c [ 16.946423][ C0] preempt_schedule+0x44/0x48 [ 16.946438][ C0] process_one_work+0x30c/0x550 [ 16.946456][ C0] worker_thread+0x414/0x8bc [ 16.946472][ C0] kthread+0x16c/0x1e0 [ 16.946486][ C0] ret_from_fork+0x10/0x20 References: - https://git.kernel.org/stable/c/74f74c8b8419a289b85aa9c85e5f4d8c2cc9f5fb - https://git.kernel.org/stable/c/977df5c13a4b253a718ec44a4eb957c612bf73f4 - https://git.kernel.org/stable/c/d2
2cc9f5fb - https://git.kernel.org/stable/c/977df5c13a4b253a718ec44a4eb957c612bf73f4 - https://git.kernel.org/stable/c/d2746c56dd2cc47f70cc3931977be556172c246d - https://git.kernel.org/stable/c/1aa161e43106d46ca8e9a86f4aa28d420258134b
CVE ID: CVE-2023-53263 State: PUBLISHED Published: 2025-09-16T08:06:53.994Z Last Updated: 2025-09-16T08:06:53.994Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create We can't simply free the connector after calling drm_connector_init on it. We need to clean up the drm side first. It might not fix all regressions from commit 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts"), but at least it fixes a memory corruption in error handling related to that commit. References: - https://git.kernel.org/stable/c/3f27451c9f29d
memory corruption in error handling related to that commit. References: - https://git.kernel.org/stable/c/3f27451c9f29d5ed00232968680c7838a44dcac7 - https://git.kernel.org/stable/c/872feeecd08c81d212a52211d212897b8a857544 - https://git.kernel.org/stable/c/1b254b791d7b7dea6e8adc887fbbd51746d8bb27
CVE ID: CVE-2023-53264 State: PUBLISHED Published: 2025-09-16T08:06:54.827Z Last Updated: 2025-09-16T08:06:54.827Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: clk: imx: clk-imxrt1050: fix memory leak in imxrt1050_clocks_probe Use devm_of_iomap() instead of of_iomap() to automatically handle the unused ioremap region. If any error occurs, regions allocated by kzalloc() will leak, but using devm_kzalloc() instead will automatically free the memory using devm_kfree(). Also, fix error handling of hws by adding unregister_hws label, which unregisters remaining hws when iomap failed. References: - https://git.kernel.org/stable/c/1
unregister_hws label, which unregisters remaining hws when iomap failed. References: - https://git.kernel.org/stable/c/1839032251a66f2ae5a043c495532830a55d28c4 - https://git.kernel.org/stable/c/0fbdfd2542252e4c02e8158a06b7c0c9cfd40f99 - https://git.kernel.org/stable/c/02e54db221bb001b32f839e0149ee8d890ab9aa1 - https://git.kernel.org/stable/c/1b280598ab3bd8a2dc8b96a12530d5b1ee7a8f4a
CVE ID: CVE-2023-53265 State: PUBLISHED Published: 2025-09-16T08:06:55.695Z Last Updated: 2025-09-16T08:06:55.695Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ubi: ensure that VID header offset + VID header size <= alloc, size Ensure that the VID header offset + VID header size does not exceed the allocated area to avoid slab OOB. BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline] BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline] BUG: KASAN: slab-out-of-bounds in crc32_le_base+0x58c/0x626 lib/crc32.c:197 Read of size 4 at addr ffff88802bb36f00 by task syz-executor136/1555 CPU: 2 P
crc32_le_base+0x58c/0x626 lib/crc32.c:197 Read of size 4 at addr ffff88802bb36f00 by task syz-executor136/1555 CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G W 6.0.0-1868 #1 Hardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x85/0xad lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433 kasan_report+0xa7/0x11b mm/kasan/report.c:495 crc32_body lib/crc32.c:111 [inline] crc32_le_generic lib/crc32.c:179 [inline] crc32_le_base+0x58c/0x626 lib/crc32.c:197 ubi_io_write_vid_hdr+0x1b7/0x472 drivers/mtd/ubi/io.c:10
/crc32.c:179 [inline] crc32_le_base+0x58c/0x626 lib/crc32.c:197 ubi_io_write_vid_hdr+0x1b7/0x472 drivers/mtd/ubi/io.c:1067 create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317 create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline] ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3e/0x86 arch/x86/en
_ioctl+0x193/0x213 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0x0 RIP: 0033:0x7f96d5cf753d Code: RSP: 002b:00007fffd72206f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f96d5cf753d RDX: 0000000020000080 RSI: 0000000040186f40 RDI: 0000000000000003 RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400be0 R13: 00007fffd72207e0 R14: 0000000000000000 R15: 0000000000000000 </TASK> Allocated by task 1555: kasan_save_stack+0x20/0x3d mm/kasan/common.c:38 kasan_set_tr
00000 R15: 0000000000000000 </TASK> Allocated by task 1555: kasan_save_stack+0x20/0x3d mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline] ____kasan_kmalloc mm/kasan/common.c:516 [inline] __kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525 kasan_kmalloc include/linux/kasan.h:234 [inline] __kmalloc+0x138/0x257 mm/slub.c:4429 kmalloc include/linux/slab.h:605 [inline] ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [inline] create_vtbl+0xcc/0x9c4 drivers/mtd/ubi/vtbl.c:295 create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline] ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 u
e] ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965 ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0x0 The buggy address belongs to the object at ffff88802bb36e00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes to the right of 256-b
802bb36e00 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes to the right of 256-byte region [ffff88802bb36e00, ffff88802bb36f00) The buggy address belongs to the physical page: page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2bb36 head:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0 flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0010200 ffffea000066c300 dead000000000003 ffff888100042b40 raw: 0000000000000000 00000000001 ---truncated--- References: - https://git.kernel.org/stable/c/61e04db3bec87f7dd10074296deb7d083e2ccade - https://git.kernel.org/stable/c/771e207a839
- https://git.kernel.org/stable/c/61e04db3bec87f7dd10074296deb7d083e2ccade - https://git.kernel.org/stable/c/771e207a839a29ba943e89f473b0fecd16089e2e - https://git.kernel.org/stable/c/f7adb740f97b6fa84e658892dcb08e37a31a4e77 - https://git.kernel.org/stable/c/846bfba34175c23b13cc2023c2d67b96e8c14c43 - https://git.kernel.org/stable/c/701bb3ed5a88a73ebbe1266895bdeff065226dca - https://git.kernel.org/stable/c/61aeba0e4b4124cfe3c5427feaf29c626dfa89e5 - https://git.kernel.org/stable/c/e1b73fe4f4c6bb80755eb4bf4b867a8fd8b1a7fe - https://git.kernel.org/stable/c/1b42b1a36fc946f0d7088425b90d491b4257ca3e
CVE ID: CVE-2023-53266 State: PUBLISHED Published: 2025-09-16T08:06:56.578Z Last Updated: 2025-09-16T08:06:56.578Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm64: acpi: Fix possible memory leak of ffh_ctxt Allocated 'ffh_ctxt' memory leak is possible if the SMCCC version and conduit checks fail and -EOPNOTSUPP is returned without freeing the allocated memory. Fix the same by moving the allocation after the SMCCC version and conduit checks. References: - https://git.kernel.org/stable/c/7521da2eb42d65f89f511b7912d3757cf3d9168a - https://git.kernel.org/stable/c/1b561d3949f8478c5403c9752b5533211a757226
CVE ID: CVE-2023-53267 State: PUBLISHED Published: 2025-09-16T08:06:57.439Z Last Updated: 2025-09-16T08:06:57.439Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: driver: soc: xilinx: fix memory leak in xlnx_add_cb_for_notify_event() The kfree() should be called when memory fails to be allocated for cb_data in xlnx_add_cb_for_notify_event(), otherwise there will be a memory leak, so add kfree() to fix it. References: - https://git.kernel.org/stable/c/d35290addcbac94b076babe0a798a8c043421812 - https://git.kernel.org/stable/c/9dfb6c784e385f6e61994bb4e16ce12f3e4940be - https://git.kernel.org/stable/c/1bea534991b9b35c41848a397666ada
.org/stable/c/9dfb6c784e385f6e61994bb4e16ce12f3e4940be - https://git.kernel.org/stable/c/1bea534991b9b35c41848a397666ada436456beb
CVE ID: CVE-2023-53268 State: PUBLISHED Published: 2025-09-16T08:06:58.237Z Last Updated: 2025-09-16T08:06:58.237Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl_mqs: move of_node_put() to the correct location of_node_put() should have been done directly after mqs_priv->regmap = syscon_node_to_regmap(gpr_np); otherwise it creates a reference leak on the success path. To fix this, of_node_put() is moved to the correct location, and change all the gotos to direct returns. References: - https://git.kernel.org/stable/c/b5a6930fc6a432e32714c4ed3c597077d999cf6d - https://git.kernel.org/stable/c/6a129c0e9935112ecf2ffb6de98f8
el.org/stable/c/b5a6930fc6a432e32714c4ed3c597077d999cf6d - https://git.kernel.org/stable/c/6a129c0e9935112ecf2ffb6de98f83b8fd090c86 - https://git.kernel.org/stable/c/402299cca89273b62384b5f9645ea49cd5fc4a57 - https://git.kernel.org/stable/c/9a2585088a7d6f98a5a910f5b4b74b6d24e63156 - https://git.kernel.org/stable/c/1bdb4a5ccab2316935ce4ad4fd4df8d36f0ffc6e - https://git.kernel.org/stable/c/1c34890273a020d61d6127ade3f68ed1cb21c16a
CVE ID: CVE-2023-53269 State: PUBLISHED Published: 2025-09-16T08:06:58.983Z Last Updated: 2025-09-16T08:06:58.983Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: block: ublk: make sure that block size is set correctly block size is one very key setting for block layer, and bad block size could panic kernel easily. Make sure that block size is set correctly. Meantime if ublk_validate_params() fails, clear ub->params so that disk is prevented from being added. References: - https://git.kernel.org/stable/c/231a49460ac0203270da2471928d392e5586370f - https://git.kernel.org/stable/c/9dbe85ac618ef6ae60abe5dd17ae2b29065d9c1e - https://
460ac0203270da2471928d392e5586370f - https://git.kernel.org/stable/c/9dbe85ac618ef6ae60abe5dd17ae2b29065d9c1e - https://git.kernel.org/stable/c/1d1665279a845d16c93687389e364386e3fe0f38
CVE ID: CVE-2023-53270 State: PUBLISHED Published: 2025-09-16T08:06:59.730Z Last Updated: 2025-09-16T08:06:59.730Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_disksize exceeding i_size problem in paritally written case It is possible for i_disksize can exceed i_size, triggering a warning. generic_perform_write copied = iov_iter_copy_from_user_atomic(len) // copied < len ext4_da_write_end | ext4_update_i_disksize | new_i_size = pos + copied; | WRITE_ONCE(EXT4_I(inode)->i_disksize, newsize) // update i_disksize | generic_write_end | copied = block_write_end(copied, len) // copied = 0 | if (unlikely(copied < len)) |
ate i_disksize | generic_write_end | copied = block_write_end(copied, len) // copied = 0 | if (unlikely(copied < len)) | if (!PageUptodate(page)) | copied = 0; | if (pos + copied > inode->i_size) // return false if (unlikely(copied == 0)) goto again; if (unlikely(iov_iter_fault_in_readable(i, bytes))) { status = -EFAULT; break; } We get i_disksize greater than i_size here, which could trigger WARNING check 'i_size_read(inode) < EXT4_I(inode)->i_disksize' while doing dio: ext4_dio_write_iter iomap_dio_rw __iomap_dio_rw // return err, length is not aligned to 512 ext4_handle_inode_extension WARN_ON_ONCE(i_size_read(inode) < EXT4_I(inode)->i_disksize) // Oops WARNING: CPU: 2 PID: 2609 at fs/ext
inode_extension WARN_ON_ONCE(i_size_read(inode) < EXT4_I(inode)->i_disksize) // Oops WARNING: CPU: 2 PID: 2609 at fs/ext4/file.c:319 CPU: 2 PID: 2609 Comm: aa Not tainted 6.3.0-rc2 RIP: 0010:ext4_file_write_iter+0xbc7 Call Trace: vfs_write+0x3b1 ksys_write+0x77 do_syscall_64+0x39 Fix it by updating 'copied' value before updating i_disksize just like ext4_write_inline_data_end() does. A reproducer can be found in the buganizer link below. References: - https://git.kernel.org/stable/c/18eb23891aeae3229baf8c7c23b76be3364e1967 - https://git.kernel.org/stable/c/d30090eb546d993ea3f3023452540c476ea614a5 - https://git.kernel.org/stable/c/3ecea2fee14227712694c8b54ad99d471e61de92 - https://git.kernel.
3f3023452540c476ea614a5 - https://git.kernel.org/stable/c/3ecea2fee14227712694c8b54ad99d471e61de92 - https://git.kernel.org/stable/c/53877ed201baa6b58f7ce9df92664a839113c30e - https://git.kernel.org/stable/c/1dedde690303c05ef732b7c5c8356fdf60a4ade3
CVE ID: CVE-2023-53271 State: PUBLISHED Published: 2025-09-16T08:07:00.565Z Last Updated: 2025-09-16T08:07:00.565Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume() There is a memory leaks problem reported by kmemleak: unreferenced object 0xffff888102007a00 (size 128): comm "ubirsvol", pid 32090, jiffies 4298464136 (age 2361.231s) hex dump (first 32 bytes): ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace: [<ffffffff8176cecd>] __kmalloc+0x4d/0x150 [<ffffffffa02a9a36>] u
ff ff ff ff ff ff ff ff ff ................ backtrace: [<ffffffff8176cecd>] __kmalloc+0x4d/0x150 [<ffffffffa02a9a36>] ubi_eba_create_table+0x76/0x170 [ubi] [<ffffffffa029764e>] ubi_resize_volume+0x1be/0xbc0 [ubi] [<ffffffffa02a3321>] ubi_cdev_ioctl+0x701/0x1850 [ubi] [<ffffffff81975d2d>] __x64_sys_ioctl+0x11d/0x170 [<ffffffff83c142a5>] do_syscall_64+0x35/0x80 [<ffffffff83e0006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 This is due to a mismatch between create and destroy interfaces, and in detail that "new_eba_tbl" created by ubi_eba_create_table() but destroyed by kfree(), while will causing "new_eba_tbl->entries" not freed. Fix it by replacing kfree(new_eba_tbl) with ubi_eba_destroy_tabl
), while will causing "new_eba_tbl->entries" not freed. Fix it by replacing kfree(new_eba_tbl) with ubi_eba_destroy_table(new_eba_tbl) References: - https://git.kernel.org/stable/c/09780a44093b53f9cbca76246af2e4ff0884e512 - https://git.kernel.org/stable/c/26ec2d66aecab8ff997b912c20247fedba4f5740 - https://git.kernel.org/stable/c/07b60f7452d2fa731737552937cb81821919f874 - https://git.kernel.org/stable/c/31d60afe2cc2b712dbefcaab6b7d6a47036f844e - https://git.kernel.org/stable/c/95a72417dd13ebcdcb1bd0c5d4d15f7c5bfbb288 - https://git.kernel.org/stable/c/27b760b81951d8d5e5c952a696af8574052b0709 - https://git.kernel.org/stable/c/5c0c81a313492b83bd0c038b8839b0e04eb87563 - https://git.kernel.org/sta
96af8574052b0709 - https://git.kernel.org/stable/c/5c0c81a313492b83bd0c038b8839b0e04eb87563 - https://git.kernel.org/stable/c/1e591ea072df7211f64542a09482b5f81cb3ad27
CVE ID: CVE-2023-53272 State: PUBLISHED Published: 2025-09-16T08:07:01.589Z Last Updated: 2025-09-16T08:07:01.589Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: ena: fix shift-out-of-bounds in exponential backoff The ENA adapters on our instances occasionally reset. Once recently logged a UBSAN failure to console in the process: UBSAN: shift-out-of-bounds in build/linux/drivers/net/ethernet/amazon/ena/ena_com.c:540:13 shift exponent 32 is too large for 32-bit type 'unsigned int' CPU: 28 PID: 70012 Comm: kworker/u72:2 Kdump: loaded not tainted 5.15.117 Hardware name: Amazon EC2 c5d.9xlarge/, BIOS 1.0 10/16/2017 Workqueue:
kworker/u72:2 Kdump: loaded not tainted 5.15.117 Hardware name: Amazon EC2 c5d.9xlarge/, BIOS 1.0 10/16/2017 Workqueue: ena ena_fw_reset_device [ena] Call Trace: <TASK> dump_stack_lvl+0x4a/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x36 __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e ? __const_udelay+0x43/0x50 ena_delay_exponential_backoff_us.cold+0x16/0x1e [ena] wait_for_reset_state+0x54/0xa0 [ena] ena_com_dev_reset+0xc8/0x110 [ena] ena_down+0x3fe/0x480 [ena] ena_destroy_device+0xeb/0xf0 [ena] ena_fw_reset_device+0x30/0x50 [ena] process_one_work+0x22b/0x3d0 worker_thread+0x4d/0x3f0 ? process_one_work+0x3d0/0x3d0 kthread+0x12a/0x150 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30
ead+0x4d/0x3f0 ? process_one_work+0x3d0/0x3d0 kthread+0x12a/0x150 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 </TASK> Apparently, the reset delays are getting so large they can trigger a UBSAN panic. Looking at the code, the current timeout is capped at 5000us. Using a base value of 100us, the current code will overflow after (1<<29). Even at values before 32, this function wraps around, perhaps unintentionally. Cap the value of the exponent used for this backoff at (1<<16) which is larger than currently necessary, but large enough to support bigger values in the future. References: - https://git.kernel.org/stable/c/1e760b2d18bf129b3da052c2946c02758e97d15e - https://git.kernel.org
future. References: - https://git.kernel.org/stable/c/1e760b2d18bf129b3da052c2946c02758e97d15e - https://git.kernel.org/stable/c/3e36cc94d6e60a27f27498adf1c71eeba769ab33 - https://git.kernel.org/stable/c/90947ebf8794e3c229fb2e16e37f1bfea6877f14 - https://git.kernel.org/stable/c/0939c264729d4a081ff88efce2ffdf85dc5331e0 - https://git.kernel.org/stable/c/1e9cb763e9bacf0c932aa948f50dcfca6f519a26
CVE ID: CVE-2023-53273 State: PUBLISHED Published: 2025-09-16T08:11:08.792Z Last Updated: 2025-09-16T08:11:08.792Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Drivers: vmbus: Check for channel allocation before looking up relids relid2channel() assumes vmbus channel array to be allocated when called. However, in cases such as kdump/kexec, not all relids will be reset by the host. When the second kernel boots and if the guest receives a vmbus interrupt during vmbus driver initialization before vmbus_connect() is called, before it finishes, or if it fails, the vmbus interrupt service routine is called which in turn calls relid
) is called, before it finishes, or if it fails, the vmbus interrupt service routine is called which in turn calls relid2channel() and can cause a null pointer dereference. Print a warning and error out in relid2channel() for a channel id that's invalid in the second kernel. References: - https://git.kernel.org/stable/c/176c6b4889195fbe7016d9401175b48c5c9edf68 - https://git.kernel.org/stable/c/c373e49fbb87aa177819866ed9194ebc5414dfd6 - https://git.kernel.org/stable/c/8c3f0ae5435fd20bb1e3a8308488aa6ac33151ee - https://git.kernel.org/stable/c/a5c44f3446a0565139b7d8abc78f58b86c398123 - https://git.kernel.org/stable/c/1eb65c8687316c65140b48fad27133d583178e15
CVE ID: CVE-2023-53274 State: PUBLISHED Published: 2025-09-16T08:11:09.549Z Last Updated: 2025-09-16T08:11:09.549Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: mt8183: Add back SSPM related clocks This reverts commit 860690a93ef23b567f781c1b631623e27190f101. On the MT8183, the SSPM related clocks were removed claiming a lack of usage. This however causes some issues when the driver was converted to the new simple-probe mechanism. This mechanism allocates enough space for all the clocks defined in the clock driver, not the highest index in the DT binding. This leads to out-of-bound writes if their are holes in t
in the clock driver, not the highest index in the DT binding. This leads to out-of-bound writes if their are holes in the DT binding or the driver (due to deprecated or unimplemented clocks). These errors can go unnoticed and cause memory corruption, leading to crashes in unrelated areas, or nothing at all. KASAN will detect them. Add the SSPM related clocks back to the MT8183 clock driver to fully implement the DT binding. The SSPM clocks are for the power management co-processor, and should never be turned off. They are marked as such. References: - https://git.kernel.org/stable/c/45d69917a4af6c869193f95932dc6d6f15d5ef86 - https://git.kernel.org/stable/c/1eb8d61ac5c9c7ec56bb96d43353280750
g/stable/c/45d69917a4af6c869193f95932dc6d6f15d5ef86 - https://git.kernel.org/stable/c/1eb8d61ac5c9c7ec56bb96d433532807509b9288
CVE ID: CVE-2023-53275 State: PUBLISHED Published: 2025-09-16T08:11:10.475Z Last Updated: 2025-09-16T08:11:10.475Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync() The variable codec->regmap is often protected by the lock codec->regmap_lock when is accessed. However, it is accessed without holding the lock when is accessed in snd_hdac_regmap_sync(): if (codec->regmap) In my opinion, this may be a harmful race, because if codec->regmap is set to NULL right after the condition is checked, a null-pointer dereference can occur in the called