Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-50428 State: PUBLISHED Published: 2025-10-01T11:42:07.245Z Last Updated: 2025-10-01T11:42:07.245Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix off-by-one errors in fast-commit block filling Due to several different off-by-one errors, or perhaps due to a late change in design that wasn't fully reflected in the code that was actually merged, there are several very strange constraints on how fast-commit blocks are filled with tlv entries: - tlvs must start at least 10 bytes before the end of the block, even though the minimum tlv length is 8. Otherwise, the replay code will ignore them. (BUG: ext4_fc_r
end of the block, even though the minimum tlv length is 8. Otherwise, the replay code will ignore them. (BUG: ext4_fc_reserve_space() could violate this requirement if called with a len of blocksize - 9 or blocksize - 8. Fortunately, this doesn't seem to happen currently.) - tlvs must end at least 1 byte before the end of the block. Otherwise the replay code will consider them to be invalid. This quirk contributed to a bug (fixed by an earlier commit) where uninitialized memory was being leaked to disk in the last byte of blocks. Also, strangely these constraints don't apply to the replay code in e2fsprogs, which will accept any tlvs in the blocks (with no bounds checks at all, but that is
ly to the replay code in e2fsprogs, which will accept any tlvs in the blocks (with no bounds checks at all, but that is a separate issue...). Given that this all seems to be a bug, let's fix it by just filling blocks with tlv entries in the natural way. Note that old kernels will be unable to replay fast-commit journals created by kernels that have this commit. References: - https://git.kernel.org/stable/c/18f28f13301d1afb8cea9c4ddcecdbff14488ec6 - https://git.kernel.org/stable/c/5ca65dffdead16572ca046c43fb576b227f7f635 - https://git.kernel.org/stable/c/5439ad45c0d0c8db41eb6f4dce6f778f15a5ee16 - https://git.kernel.org/stable/c/48a6a66db82b8043d298a630f22c62d43550cae5
CVE ID: CVE-2022-50429 State: PUBLISHED Published: 2025-10-01T11:42:07.973Z Last Updated: 2025-10-01T11:42:07.973Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: memory: of: Fix refcount leak bug in of_lpddr3_get_ddr_timings() We should add the of_node_put() when breaking out of for_each_child_of_node() as it will automatically increase and decrease the refcount. References: - https://git.kernel.org/stable/c/1d312c12c91f831fcc48623c921f2d4560edb159 - https://git.kernel.org/stable/c/7e053784c4c70df28324106d476778be7a4519b3 - https://git.kernel.org/stable/c/daab421fc2dc7d6ae7eb20a3f565ae09652c68b9 - https://git.kernel.org/stable/
78be7a4519b3 - https://git.kernel.org/stable/c/daab421fc2dc7d6ae7eb20a3f565ae09652c68b9 - https://git.kernel.org/stable/c/3b321bf7687968a090cf6b62bd8e67d692f59a16 - https://git.kernel.org/stable/c/48af14fb0eaa63d9aa68f59fb0b205ec55a95636
CVE ID: CVE-2022-50430 State: PUBLISHED Published: 2025-10-01T11:42:08.708Z Last Updated: 2025-10-01T11:42:08.708Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix warning - do not call blocking ops when !TASK_RUNNING vub300_enable_sdio_irq() works with mutex and need TASK_RUNNING here. Ensure that we mark current as TASK_RUNNING for sleepable context. [ 77.554641] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff92a72c1d>] sdio_irq_thread+0x17d/0x5b0 [ 77.554652] WARNING: CPU: 2 PID: 1983 at kernel/sched/core.c:9813 __might_sleep+0x116/0x160 [ 77.554905] CPU: 2 PID: 1983 Comm: ksdioirqd/mmc1
PU: 2 PID: 1983 at kernel/sched/core.c:9813 __might_sleep+0x116/0x160 [ 77.554905] CPU: 2 PID: 1983 Comm: ksdioirqd/mmc1 Tainted: G OE 6.1.0-rc5 #1 [ 77.554910] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, BIOS BECFL357.86A.0081.2020.0504.1834 05/04/2020 [ 77.554912] RIP: 0010:__might_sleep+0x116/0x160 [ 77.554920] RSP: 0018:ffff888107b7fdb8 EFLAGS: 00010282 [ 77.554923] RAX: 0000000000000000 RBX: ffff888118c1b740 RCX: 0000000000000000 [ 77.554926] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffffed1020f6ffa9 [ 77.554928] RBP: ffff888107b7fde0 R08: 0000000000000001 R09: ffffed1043ea60ba [ 77.554930] R10: ffff88821f5305cb R11: ffffed1043ea60b9 R12: ffffffff93aa3a60 [ 77.55493
00000001 R09: ffffed1043ea60ba [ 77.554930] R10: ffff88821f5305cb R11: ffffed1043ea60b9 R12: ffffffff93aa3a60 [ 77.554932] R13: 000000000000011b R14: 7fffffffffffffff R15: ffffffffc0558660 [ 77.554934] FS: 0000000000000000(0000) GS:ffff88821f500000(0000) knlGS:0000000000000000 [ 77.554937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 77.554939] CR2: 00007f8a44010d68 CR3: 000000024421a003 CR4: 00000000003706e0 [ 77.554942] Call Trace: [ 77.554944] <TASK> [ 77.554952] mutex_lock+0x78/0xf0 [ 77.554973] vub300_enable_sdio_irq+0x103/0x3c0 [vub300] [ 77.554981] sdio_irq_thread+0x25c/0x5b0 [ 77.555006] kthread+0x2b8/0x370 [ 77.555017] ret_from_fork+0x1f/0x30 [ 77.555023] </TASK> [ 77.555025]
ead+0x25c/0x5b0 [ 77.555006] kthread+0x2b8/0x370 [ 77.555017] ret_from_fork+0x1f/0x30 [ 77.555023] </TASK> [ 77.555025] ---[ end trace 0000000000000000 ]--- References: - https://git.kernel.org/stable/c/32d5af247d4de6a35769ca1d027480a37c28fd0c - https://git.kernel.org/stable/c/48e91ae755f027d817ed7e51db9963ddb7081946 - https://git.kernel.org/stable/c/6f7258c6f66692b3760c37ddd4bc9e02bb290da7 - https://git.kernel.org/stable/c/f1c08947ab0538b07a0bd9d6edadfb5185f56344 - https://git.kernel.org/stable/c/b51d5fed9f53e07ce9fc65efb4ff1abe021a4c16 - https://git.kernel.org/stable/c/d58289fc77f8c1f879c818bddaf7ef524c73658b - https://git.kernel.org/stable/c/d15946ef98f4ccdca961b76f90d9b53c454d590e - http
8289fc77f8c1f879c818bddaf7ef524c73658b - https://git.kernel.org/stable/c/d15946ef98f4ccdca961b76f90d9b53c454d590e - https://git.kernel.org/stable/c/ba2e7d07dd06e646a72ba906a89fdc1cca7ea560 - https://git.kernel.org/stable/c/4a44cd249604e29e7b90ae796d7692f5773dd348
CVE ID: CVE-2022-50431 State: PUBLISHED Published: 2025-10-01T11:42:09.700Z Last Updated: 2025-10-01T11:42:09.700Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: aoa: i2sbus: fix possible memory leak in i2sbus_add_dev() dev_set_name() in soundbus_add_one() allocates memory for name, it need be freed when of_device_register() fails, call soundbus_dev_put() to give up the reference that hold in device_initialize(), so that it can be freed in kobject_cleanup() when the refcount hit to 0. And other resources are also freed in i2sbus_release_dev(), so it can return 0 directly. References: - https://git.kernel.org/stable/c/fd41
are also freed in i2sbus_release_dev(), so it can return 0 directly. References: - https://git.kernel.org/stable/c/fd410d24665e4efb3c1796797181265efe553e9c - https://git.kernel.org/stable/c/802532a50acf501fdafe38a84ca2aa886d68af68 - https://git.kernel.org/stable/c/027fee10e3a400cf6f3237374a1248da1082807b - https://git.kernel.org/stable/c/5bdea674534153110b90d70b02f2fbaf48b2c0eb - https://git.kernel.org/stable/c/ce6fd1c382a38b75557db85a2fe99d285540a03d - https://git.kernel.org/stable/c/e81d7826b8f40430a1ea1b330e24d9a9eb4512c4 - https://git.kernel.org/stable/c/c7524279c8ddc7dbf3463bec70e0289097959944 - https://git.kernel.org/stable/c/4a4c8482e370d697738a78dcd7bf2780832cb712
CVE ID: CVE-2022-50432 State: PUBLISHED Published: 2025-10-01T11:42:10.573Z Last Updated: 2025-10-01T11:42:10.573Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: kernfs: fix use-after-free in __kernfs_remove Syzkaller managed to trigger concurrent calls to kernfs_remove_by_name_ns() for the same file resulting in a KASAN detected use-after-free. The race occurs when the root node is freed during kernfs_drain(). To prevent this acquire an additional reference for the root of the tree that is removed before calling __kernfs_remove(). Found by syzkaller with the following reproducer (slab_nomerge is required): syz_mount_image$ext4
ing __kernfs_remove(). Found by syzkaller with the following reproducer (slab_nomerge is required): syz_mount_image$ext4(0x0, &(0x7f0000000100)='./file0\x00', 0x100000, 0x0, 0x0, 0x0, 0x0) r0 = openat(0xffffffffffffff9c, &(0x7f0000000080)='/proc/self/exe\x00', 0x0, 0x0) close(r0) pipe2(&(0x7f0000000140)={0xffffffffffffffff, <r1=>0xffffffffffffffff}, 0x800) mount$9p_fd(0x0, &(0x7f0000000040)='./file0\x00', &(0x7f00000000c0), 0x408, &(0x7f0000000280)={'trans=fd,', {'rfdno', 0x3d, r0}, 0x2c, {'wfdno', 0x3d, r1}, 0x2c, {[{@cache_loose}, {@mmap}, {@loose}, {@loose}, {@mmap}], [{@mask={'mask', 0x3d, '^MAY_EXEC'}}, {@fsmagic={'fsmagic', 0x3d, 0x10001}}, {@dont_hash}]}}) Sample report: =============
@mask={'mask', 0x3d, '^MAY_EXEC'}}, {@fsmagic={'fsmagic', 0x3d, 0x10001}}, {@dont_hash}]}}) Sample report: ================================================================== BUG: KASAN: use-after-free in kernfs_type include/linux/kernfs.h:335 [inline] BUG: KASAN: use-after-free in kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline] BUG: KASAN: use-after-free in __kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369 Read of size 2 at addr ffff8880088807f0 by task syz-executor.2/857 CPU: 0 PID: 857 Comm: syz-executor.2 Not tainted 6.0.0-rc3-00363-g7726d4c3e60b #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack
re name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x6e/0x91 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x5e/0x5e5 mm/kasan/report.c:433 kasan_report+0xa3/0x130 mm/kasan/report.c:495 kernfs_type include/linux/kernfs.h:335 [inline] kernfs_leftmost_descendant fs/kernfs/dir.c:1261 [inline] __kernfs_remove.part.0+0x843/0x960 fs/kernfs/dir.c:1369 __kernfs_remove fs/kernfs/dir.c:1356 [inline] kernfs_remove_by_name_ns+0x108/0x190 fs/kernfs/dir.c:1589 sysfs_slab_add+0x133/0x1e0 mm/slub.c:5943 __kmem_cache_create+0x3e0/0x550 mm/slub.c:4899 create_cach
s/kernfs/dir.c:1589 sysfs_slab_add+0x133/0x1e0 mm/slub.c:5943 __kmem_cache_create+0x3e0/0x550 mm/slub.c:4899 create_cache mm/slab_common.c:229 [inline] kmem_cache_create_usercopy+0x167/0x2a0 mm/slab_common.c:335 p9_client_create+0xd4d/0x1190 net/9p/client.c:993 v9fs_session_init+0x1e6/0x13c0 fs/9p/v9fs.c:408 v9fs_mount+0xb9/0xbd0 fs/9p/vfs_super.c:126 legacy_get_tree+0xf1/0x200 fs/fs_context.c:610 vfs_get_tree+0x85/0x2e0 fs/super.c:1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x675/0x1d00 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x282/0x300 fs/namespace.c:3568
fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x282/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f725f983aed Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f725f0f7028 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f725faa3f80 RCX: 00007f725f983aed RDX: 00000000200000c0 RSI: 0000000020000040 RDI: 0000000000000000 RBP: 000
a RBX: 00007f725faa3f80 RCX: 00007f725f983aed RDX: 00000000200000c0 RSI: 0000000020000040 RDI: 0000000000000000 RBP: 00007f725f9f419c R08: 0000000020000280 R09: 0000000000000000 R10: 0000000000000408 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000006 R14: 00007f725faa3f80 R15: 00007f725f0d7000 </TASK> Allocated by task 855: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:470 kasan_slab_alloc include/linux/kasan.h:224 [inline] slab_post_alloc_hook mm/slab.h:7 ---truncated--- References: - https://git.kernel.org/stable/c/4dfd6a477a1525773469f
ne] slab_post_alloc_hook mm/slab.h:7 ---truncated--- References: - https://git.kernel.org/stable/c/4dfd6a477a1525773469feaf3c514b2c0fef76b5 - https://git.kernel.org/stable/c/02eb35131050735332658029082f61515b7dfe38 - https://git.kernel.org/stable/c/028cf780743eea79abffa7206b9dcfc080ad3546 - https://git.kernel.org/stable/c/c78b0dc6fb7fb389d674e491fd376388cdfb1d53 - https://git.kernel.org/stable/c/6f72a3977ba9d0e5491a5c01315204272e7f9c44 - https://git.kernel.org/stable/c/94d2643df1e70a4c310ebb5e2c493eec33df1a06 - https://git.kernel.org/stable/c/af1b57cc39beca203559576b3046094fc9e5eb32 - https://git.kernel.org/stable/c/4abc99652812a2ddf932f137515d5c5a04723538
CVE ID: CVE-2022-50433 State: PUBLISHED Published: 2025-10-01T11:42:11.444Z Last Updated: 2025-10-01T11:42:11.444Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: efi: ssdt: Don't free memory if ACPI table was loaded successfully Amadeusz reports KASAN use-after-free errors introduced by commit 3881ee0b1edc ("efi: avoid efivars layer when loading SSDTs from variables"). The problem appears to be that the memory that holds the new ACPI table is now freed unconditionally, instead of only when the ACPI core reported a failure to load the table. So let's fix this, by omitting the kfree() on success. References: - https://git.kernel.
ed a failure to load the table. So let's fix this, by omitting the kfree() on success. References: - https://git.kernel.org/stable/c/11497fd69cd2282538ec6eb4cda1d16fc061233d - https://git.kernel.org/stable/c/4b017e59f01097f19b938f6dc4dc2c4720701610
CVE ID: CVE-2022-50434 State: PUBLISHED Published: 2025-10-01T11:42:12.160Z Last Updated: 2025-10-01T11:42:12.160Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix possible memleak when register 'hctx' failed There's issue as follows when do fault injection test: unreferenced object 0xffff888132a9f400 (size 512): comm "insmod", pid 308021, jiffies 4324277909 (age 509.733s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 f4 a9 32 81 88 ff ff ...........2.... 08 f4 a9 32 81 88 ff ff 00 00 00 00 00 00 00 00 ...2............ backtrace: [<00000000e8952bb4>] kmalloc_node_trace+0x22/0xa0 [<00000000f9980e0f>] blk_mq_all
0 00 00 00 ...2............ backtrace: [<00000000e8952bb4>] kmalloc_node_trace+0x22/0xa0 [<00000000f9980e0f>] blk_mq_alloc_and_init_hctx+0x3f1/0x7e0 [<000000002e719efa>] blk_mq_realloc_hw_ctxs+0x1e6/0x230 [<000000004f1fda40>] blk_mq_init_allocated_queue+0x27e/0x910 [<00000000287123ec>] __blk_mq_alloc_disk+0x67/0xf0 [<00000000a2a34657>] 0xffffffffa2ad310f [<00000000b173f718>] 0xffffffffa2af824a [<0000000095a1dabb>] do_one_initcall+0x87/0x2a0 [<00000000f32fdf93>] do_init_module+0xdf/0x320 [<00000000cbe8541e>] load_module+0x3006/0x3390 [<0000000069ed1bdb>] __do_sys_finit_module+0x113/0x1b0 [<00000000a1a29ae8>] do_syscall_64+0x35/0x80 [<000000009cd878b0>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
e+0x113/0x1b0 [<00000000a1a29ae8>] do_syscall_64+0x35/0x80 [<000000009cd878b0>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Fault injection context as follows: kobject_add blk_mq_register_hctx blk_mq_sysfs_register blk_register_queue device_add_disk null_add_dev.part.0 [null_blk] As 'blk_mq_register_hctx' may already add some objects when failed halfway, but there isn't do fallback, caller don't know which objects add failed. To solve above issue just do fallback when add objects failed halfway in 'blk_mq_register_hctx'. References: - https://git.kernel.org/stable/c/654870789c3c1b9763316ef1c71d7a449127b175 - https://git.kernel.org/stable/c/cb186eb47fb9dd327bdefa15f0c5fc55c53a40dd - https://git.
3c1b9763316ef1c71d7a449127b175 - https://git.kernel.org/stable/c/cb186eb47fb9dd327bdefa15f0c5fc55c53a40dd - https://git.kernel.org/stable/c/02bc8bc6eab03c84373281b85cb6e98747172ff7 - https://git.kernel.org/stable/c/87fd18016a47ea8ae12641377a390172c4aa97a7 - https://git.kernel.org/stable/c/e8022da1fa2fdf2fa204b445dd3354e7a66d085a - https://git.kernel.org/stable/c/eff45bfbc25a2509a6362dea6e699e14083c693c - https://git.kernel.org/stable/c/4b7fafa5f39b15c3a6ca3b95e534d05d6904cc95 - https://git.kernel.org/stable/c/33e8a3f61814ea30615d0fafaf50477975d6c1ca - https://git.kernel.org/stable/c/4b7a21c57b14fbcd0e1729150189e5933f5088e9
CVE ID: CVE-2022-50435 State: PUBLISHED Published: 2025-10-01T11:42:12.845Z Last Updated: 2025-10-01T11:42:12.845Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: avoid crash when inline data creation follows DIO write When inode is created and written to using direct IO, there is nothing to clear the EXT4_STATE_MAY_INLINE_DATA flag. Thus when inode gets truncated later to say 1 byte and written using normal write, we will try to store the data as inline data. This confuses the code later because the inode now has both normal block and inline data allocated and the confusion manifests for example as: kernel BUG at fs/ext4/
e now has both normal block and inline data allocated and the confusion manifests for example as: kernel BUG at fs/ext4/inode.c:2721! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014 RIP: 0010:ext4_writepages+0x363d/0x3660 RSP: 0018:ffffc90000ccf260 EFLAGS: 00010293 RAX: ffffffff81e1abcd RBX: 0000008000000000 RCX: ffff88810842a180 RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000 RBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b R10: dfffe910222c680c R11: 1ffff110222c680a R12: ffff888111634128 R13: fff
0 R08: ffffffff81e17d58 R09: ffffed10222c680b R10: dfffe910222c680c R11: 1ffff110222c680a R12: ffff888111634128 R13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001 FS: 00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0 Call Trace: <TASK> do_writepages+0x397/0x640 filemap_fdatawrite_wbc+0x151/0x1b0 file_write_and_wait_range+0x1c9/0x2b0 ext4_sync_file+0x19e/0xa00 vfs_fsync_range+0x17b/0x190 ext4_buffered_write_iter+0x488/0x530 ext4_file_write_iter+0x449/0x1b90 vfs_write+0xbcd/0xf40 ksys_write+0x198/0x2c0 __x64_sys_write+0x7b/0x90 do_syscall_64+0x
xt4_file_write_iter+0x449/0x1b90 vfs_write+0xbcd/0xf40 ksys_write+0x198/0x2c0 __x64_sys_write+0x7b/0x90 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> Fix the problem by clearing EXT4_STATE_MAY_INLINE_DATA when we are doing direct IO write to a file. References: - https://git.kernel.org/stable/c/3b31cc533665899965e351aae6cc3c3f3b9cc076 - https://git.kernel.org/stable/c/43ed16910af200e2fcfe16986bee1a67fba94992 - https://git.kernel.org/stable/c/59b108630a4987f71e1dc1dc50b8062e992b49c6 - https://git.kernel.org/stable/c/a22f52d883313bbfaf864669c14003f9456d4f8f - https://git.kernel.org/stable/c/fb98cb61efff3b2a1964939465ccaaf906af1d4f - https://git.kernel.org/stable/c/d8
456d4f8f - https://git.kernel.org/stable/c/fb98cb61efff3b2a1964939465ccaaf906af1d4f - https://git.kernel.org/stable/c/d8e4af8314df54d94cf2a541cf9c8626afe81d41 - https://git.kernel.org/stable/c/89db2b50469bdbccb06ab072096d9d403124abac - https://git.kernel.org/stable/c/771f15782d95760cde352c8d4bfd6f2c70719568 - https://git.kernel.org/stable/c/4bb26f2885ac6930984ee451b952c5a6042f2c0e
CVE ID: CVE-2022-50436 State: PUBLISHED Published: 2025-10-01T11:42:13.538Z Last Updated: 2025-10-01T11:42:13.538Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: don't set up encryption key during jbd2 transaction Commit a80f7fcf1867 ("ext4: fixup ext4_fc_track_* functions' signature") extended the scope of the transaction in ext4_unlink() too far, making it include the call to ext4_find_entry(). However, ext4_find_entry() can deadlock when called from within a transaction because it may need to set up the directory's encryption key. Fix this by restoring the transaction to its original scope. References: - https://git.ke
he directory's encryption key. Fix this by restoring the transaction to its original scope. References: - https://git.kernel.org/stable/c/23ad034760dd38e12b0e0e1b28b9629f330810a1 - https://git.kernel.org/stable/c/6220ec405571ded17efedc56587190b542adf246 - https://git.kernel.org/stable/c/206dd3acfb9bca54a25b228c7c7c2257eedde09b - https://git.kernel.org/stable/c/1ba993208bcfd691e241483420a2a761d3f15750 - https://git.kernel.org/stable/c/4c0d5778385cb3618ff26a561ce41de2b7d9de70
CVE ID: CVE-2022-50437 State: PUBLISHED Published: 2025-10-01T11:42:14.400Z Last Updated: 2025-10-01T11:42:14.400Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/msm/hdmi: fix memory corruption with too many bridges Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges. Patchwork: https://patchwork.freedesktop.org/patch/502670/ References: - https://git.kernel.org/stable/c/a9c1a6991a9b5aa6d0f2cbc9b8c3bf6c4d094dfa - https://git.kernel.org/stable/c/e8f916b84e4b028ecad6c6472eaad543cc7df806 - https://git.kernel.org/stable/c/
6c4d094dfa - https://git.kernel.org/stable/c/e8f916b84e4b028ecad6c6472eaad543cc7df806 - https://git.kernel.org/stable/c/3c43f3ec731c233eb84b66199ee76dbf3ec6ecae - https://git.kernel.org/stable/c/ed7f1ff87a4afea1bc220d2ff00a7ce8e61f0b53 - https://git.kernel.org/stable/c/08c7375fa27a8ceee028868e03ffb3a0db919d44 - https://git.kernel.org/stable/c/b48949ab451eaf1e2c04c272c8a9a96a2b56546f - https://git.kernel.org/stable/c/9efb45b45ff6254bfd1f1997a06725cb3fc998a5 - https://git.kernel.org/stable/c/4c1294da6aed1f16d47a417dcfe6602833c3c95c
CVE ID: CVE-2022-50438 State: PUBLISHED Published: 2025-10-01T11:42:15.118Z Last Updated: 2025-10-01T11:42:15.118Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: hinic: fix memory leak when reading function table When the input parameter idx meets the expected case option in hinic_dbg_get_func_table(), read_data is not released. Fix it. References: - https://git.kernel.org/stable/c/bb01910763f935b16538084b4269696e0de17f79 - https://git.kernel.org/stable/c/e6765fe8de372a84f8dbe9e03ec13c7c70f946b8 - https://git.kernel.org/stable/c/ee98ab337036c983239aa550850861c88a5c4262 - https://git.kernel.org/stable/c/4c1f602df8956bc0decd
/git.kernel.org/stable/c/ee98ab337036c983239aa550850861c88a5c4262 - https://git.kernel.org/stable/c/4c1f602df8956bc0decdafd7e4fc7eef50c550b1
CVE ID: CVE-2022-50439 State: PUBLISHED Published: 2025-10-01T11:42:15.829Z Last Updated: 2025-10-01T11:42:15.829Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8173: Enable IRQ when pdata is ready If the device does not come straight from reset, we might receive an IRQ before we are ready to handle it. [ 2.334737] Unable to handle kernel read from unreadable memory at virtual address 00000000000001e4 [ 2.522601] Call trace: [ 2.525040] regmap_read+0x1c/0x80 [ 2.528434] mt8173_afe_irq_handler+0x40/0xf0 ... [ 2.598921] start_kernel+0x338/0x42c References: - https://git.kernel.org/stable/c/190685ff4ee03eef8f12c
r+0x40/0xf0 ... [ 2.598921] start_kernel+0x338/0x42c References: - https://git.kernel.org/stable/c/190685ff4ee03eef8f12c71d8f626e414fa078a9 - https://git.kernel.org/stable/c/57491967ad8f865a9a81d08c36b26facd14d84e5 - https://git.kernel.org/stable/c/27e7cf595d4a9fea9d3906b47d0faa87896beeb3 - https://git.kernel.org/stable/c/9ce9c78a2bdbc9a014e7102a35834310c28528b9 - https://git.kernel.org/stable/c/77c6b6be7e80ca4a4d4b66b63fd5bb48ccefdd5a - https://git.kernel.org/stable/c/4cbb264d4e9136acab2c8fd39e39ab1b1402b84b