Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-49404 State: PUBLISHED Published: 2025-02-26T02:12:30.123Z Last Updated: 2025-10-01T19:46:50.457Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Fix potential integer multiplication overflow errors When multiplying of different types, an overflow is possible even when storing the result in a larger type. This is because the conversion is done after the multiplication. So arithmetic overflow and thus in incorrect value is possible. Correct an instance of this in the inter packet delay calculation. Fix by ensuring one of the operands is u64 which will promote the other to u64 as well ensuring no overfl
y calculation. Fix by ensuring one of the operands is u64 which will promote the other to u64 as well ensuring no overflow. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/252f4afd4557a2e7075f793a5c80fe6dd9e9ee4a - https://git.kernel.org/stable/c/a89cb7ddf6a89bab6012e19da38b7cdb26175c19 - https://git.kernel.org/stable/c/79c164e61f818054cd6012e9035701840d895c51 - https://git.kernel.org/stable/c/8858284dd74906fa00f04f0252c75df4893a7959 - https://git.kernel.org/stable/c/31dca00d0cc9f4133320d72eb7e3720badc6d6e6 - https://git.kernel.org/stable/c/3f09ec80f115d2875d747ed28adc1773037e0f8b - https://git.kernel.org/stable/c/06039d8afefdbac05bcea5f397188
el.org/stable/c/3f09ec80f115d2875d747ed28adc1773037e0f8b - https://git.kernel.org/stable/c/06039d8afefdbac05bcea5f397188407eba2996d - https://git.kernel.org/stable/c/ef5ab2e48a5f9960e2352332b7cdb7064bb49032 - https://git.kernel.org/stable/c/f93e91a0372c922c20d5bee260b0f43b4b8a1bee
CVE ID: CVE-2022-49405 State: PUBLISHED Published: 2025-02-26T02:12:30.617Z Last Updated: 2025-05-04T08:36:58.243Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: staging: r8188eu: prevent ->Ssid overflow in rtw_wx_set_scan() This code has a check to prevent read overflow but it needs another check to prevent writing beyond the end of the ->Ssid[] array. References: - https://git.kernel.org/stable/c/ac2eab7de458f5e1210ce1237afab40a307075c8 - https://git.kernel.org/stable/c/c4bd6b72df4f01aa866ceb298466d6d07a6bd525 - https://git.kernel.org/stable/c/476bfda0be0f9669add92bff604ca78226cf53d1 - https://git.kernel.org/stable/c/bc10916e
25 - https://git.kernel.org/stable/c/476bfda0be0f9669add92bff604ca78226cf53d1 - https://git.kernel.org/stable/c/bc10916e890948d8927a5c8c40fb5dc44be5e1b8
CVE ID: CVE-2022-49406 State: PUBLISHED Published: 2025-02-26T02:12:31.086Z Last Updated: 2025-10-01T19:46:50.291Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: block: Fix potential deadlock in blk_ia_range_sysfs_show() When being read, a sysfs attribute is already protected against removal with the kobject node active reference counter. As a result, in blk_ia_range_sysfs_show(), there is no need to take the queue sysfs lock when reading the value of a range attribute. Using the queue sysfs lock in this function creates a potential deadlock situation with the disk removal, something that a lockdep signals with a splat when the
ion creates a potential deadlock situation with the disk removal, something that a lockdep signals with a splat when the device is removed: [ 760.703551] Possible unsafe locking scenario: [ 760.703551] [ 760.703554] CPU0 CPU1 [ 760.703556] ---- ---- [ 760.703558] lock(&q->sysfs_lock); [ 760.703565] lock(kn->active#385); [ 760.703573] lock(&q->sysfs_lock); [ 760.703579] lock(kn->active#385); [ 760.703587] [ 760.703587] *** DEADLOCK *** Solve this by removing the mutex_lock()/mutex_unlock() calls from blk_ia_range_sysfs_show(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/dc107c805cde709866b59867ef72b9390199205e - https://git.kernel.org/stabl
t: References: - https://git.kernel.org/stable/c/dc107c805cde709866b59867ef72b9390199205e - https://git.kernel.org/stable/c/717b078bc745ba9a262abebed9806a17e8bbb77b - https://git.kernel.org/stable/c/41e46b3c2aa24f755b2ae9ec4ce931ba5f0d8532
CVE ID: CVE-2022-49407 State: PUBLISHED Published: 2025-02-26T02:12:31.562Z Last Updated: 2025-05-04T08:37:01.165Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dlm: fix plock invalid read This patch fixes an invalid read showed by KASAN. A unlock will allocate a "struct plock_op" and a followed send_op() will append it to a global send_list data structure. In some cases a followed dev_read() moves it to recv_list and dev_write() will cast it to "struct plock_xop" and access fields which are only available in those structures. At this point an invalid read happens by accessing those fields. To fix this issue the "callback" fie
those structures. At this point an invalid read happens by accessing those fields. To fix this issue the "callback" field is moved to "struct plock_op" to indicate that a cast to "plock_xop" is allowed and does the additional "plock_xop" handling if set. Example of the KASAN output which showed the invalid read: [ 2064.296453] ================================================================== [ 2064.304852] BUG: KASAN: slab-out-of-bounds in dev_write+0x52b/0x5a0 [dlm] [ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlm_controld/7484 [ 2064.308168] [ 2064.308575] CPU: 0 PID: 7484 Comm: dlm_controld Kdump: loaded Not tainted 5.14.0+ #9 [ 2064.310292] Hardware name: Red Hat KVM,
575] CPU: 0 PID: 7484 Comm: dlm_controld Kdump: loaded Not tainted 5.14.0+ #9 [ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 2064.311618] Call Trace: [ 2064.312218] dump_stack_lvl+0x56/0x7b [ 2064.313150] print_address_description.constprop.8+0x21/0x150 [ 2064.314578] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.315610] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.316595] kasan_report.cold.14+0x7f/0x11b [ 2064.317674] ? dev_write+0x52b/0x5a0 [dlm] [ 2064.318687] dev_write+0x52b/0x5a0 [dlm] [ 2064.319629] ? dev_read+0x4a0/0x4a0 [dlm] [ 2064.320713] ? bpf_lsm_kernfs_init_security+0x10/0x10 [ 2064.321926] vfs_write+0x17e/0x930 [ 2064.322769] ? __fget_light+0x1aa/0x220 [ 2064.323753] ksys_wr
security+0x10/0x10 [ 2064.321926] vfs_write+0x17e/0x930 [ 2064.322769] ? __fget_light+0x1aa/0x220 [ 2064.323753] ksys_write+0xf1/0x1c0 [ 2064.324548] ? __ia32_sys_read+0xb0/0xb0 [ 2064.325464] do_syscall_64+0x3a/0x80 [ 2064.326387] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.327606] RIP: 0033:0x7f807e4ba96f [ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48 [ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f [ 206
000293 ORIG_RAX: 0000000000000001 [ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f [ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010 [ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001 [ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80 [ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001 [ 2064.342857] [ 2064.343226] Allocated by task 12438: [ 2064.344057] kasan_save_stack+0x1c/0x40 [ 2064.345079] __kasan_kmalloc+0x84/0xa0 [ 2064.345933] kmem_cache_alloc_trace+0x13b/0x220 [ 2064.346953] dlm_posix_unlock+0xec/0x720 [dlm] [ 2064.348811] do_lock_f
064.345933] kmem_cache_alloc_trace+0x13b/0x220 [ 2064.346953] dlm_posix_unlock+0xec/0x720 [dlm] [ 2064.348811] do_lock_file_wait.part.32+0xca/0x1d0 [ 2064.351070] fcntl_setlk+0x281/0xbc0 [ 2064.352879] do_fcntl+0x5e4/0xfe0 [ 2064.354657] __x64_sys_fcntl+0x11f/0x170 [ 2064.356550] do_syscall_64+0x3a/0x80 [ 2064.358259] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 2064.360745] [ 2064.361511] Last potentially related work creation: [ 2064.363957] kasan_save_stack+0x1c/0x40 [ 2064.365811] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.368100] call_rcu+0x11b/0xf70 [ 2064.369785] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.372404] receive_from_sock+0x290/0x770 [dlm] [ 2064.374607] process_recv_s
ocess_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.372404] receive_from_sock+0x290/0x770 [dlm] [ 2064.374607] process_recv_sockets+0x32/0x40 [dlm] [ 2064.377290] process_one_work+0x9a8/0x16e0 [ 2064.379357] worker_thread+0x87/0xbf0 [ 2064.381188] kthread+0x3ac/0x490 [ 2064.383460] ret_from_fork+0x22/0x30 [ 2064.385588] [ 2064.386518] Second to last potentially related work creation: [ 2064.389219] kasan_save_stack+0x1c/0x40 [ 2064.391043] __kasan_record_aux_stack+0xaf/0xc0 [ 2064.393303] call_rcu+0x11b/0xf70 [ 2064.394885] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm] [ 2064.397694] receive_from_sock+0x290/0x770 ---truncated--- References: - https://git.kernel.org/stable/c/2c55155cc365861044d9e6
7694] receive_from_sock+0x290/0x770 ---truncated--- References: - https://git.kernel.org/stable/c/2c55155cc365861044d9e6e80e342693e8805e33 - https://git.kernel.org/stable/c/72f2f68970f9bdc252d59e119b385a6441b0b155 - https://git.kernel.org/stable/c/5a1765adf9855cf0f6d3f7e0eb4b78ca66f70dee - https://git.kernel.org/stable/c/49cd9eb7b9a7b88124b31e31f8e539acaf1b3a6d - https://git.kernel.org/stable/c/899bc4429174861122f0c236588700a4710c1fec - https://git.kernel.org/stable/c/acdad5bc9827922ec2f2e84fd198718aa8e8ab92 - https://git.kernel.org/stable/c/56aa8d1fbd02357f3bf81bdfba1cde87ce8402fc - https://git.kernel.org/stable/c/e421872fa17542cf33747071fb141b0130ce9ef7 - https://git.kernel.org/stable/c/42
ce8402fc - https://git.kernel.org/stable/c/e421872fa17542cf33747071fb141b0130ce9ef7 - https://git.kernel.org/stable/c/42252d0d2aa9b94d168241710a761588b3959019
CVE ID: CVE-2022-49408 State: PUBLISHED Published: 2025-02-26T02:12:32.048Z Last Updated: 2025-10-01T20:17:06.649Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leak in parse_apply_sb_mount_options() If processing the on-disk mount options fails after any memory was allocated in the ext4_fs_context, e.g. s_qf_names, then this memory is leaked. Fix this by calling ext4_fc_free() instead of kfree() directly. Reproducer: mkfs.ext4 -F /dev/vdc tune2fs /dev/vdc -E mount_opts=usrjquota=file echo clear > /sys/kernel/debug/kmemleak mount /dev/vdc /vdc echo scan > /sys/kernel/debug/kmemleak sleep 5 echo scan > /sys/ker
ear > /sys/kernel/debug/kmemleak mount /dev/vdc /vdc echo scan > /sys/kernel/debug/kmemleak sleep 5 echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/9ea3e6168948189cec31d0678d2b55b395f88491 - https://git.kernel.org/stable/c/f92ded66e9d0aa20b883a2a5183973abc8f41815 - https://git.kernel.org/stable/c/c069db76ed7b681c69159f44be96d2137e9ca989
CVE ID: CVE-2022-49409 State: PUBLISHED Published: 2025-02-26T02:12:32.591Z Last Updated: 2025-05-04T12:44:39.209Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug_on in __es_tree_search Hulk Robot reported a BUG_ON: ================================================================== kernel BUG at fs/ext4/extents_status.c:199! [...] RIP: 0010:ext4_es_end fs/ext4/extents_status.c:199 [inline] RIP: 0010:__es_tree_search+0x1e0/0x260 fs/ext4/extents_status.c:217 [...] Call Trace: ext4_es_cache_extent+0x109/0x340 fs/ext4/extents_status.c:766 ext4_cache_extents+0x239/0x2e0 fs/ext4/extents.c:561 ext4_find_extent+0x6b7/0xa20
109/0x340 fs/ext4/extents_status.c:766 ext4_cache_extents+0x239/0x2e0 fs/ext4/extents.c:561 ext4_find_extent+0x6b7/0xa20 fs/ext4/extents.c:964 ext4_ext_map_blocks+0x16b/0x4b70 fs/ext4/extents.c:4384 ext4_map_blocks+0xe26/0x19f0 fs/ext4/inode.c:567 ext4_getblk+0x320/0x4c0 fs/ext4/inode.c:980 ext4_bread+0x2d/0x170 fs/ext4/inode.c:1031 ext4_quota_read+0x248/0x320 fs/ext4/super.c:6257 v2_read_header+0x78/0x110 fs/quota/quota_v2.c:63 v2_check_quota_file+0x76/0x230 fs/quota/quota_v2.c:82 vfs_load_quota_inode+0x5d1/0x1530 fs/quota/dquot.c:2368 dquot_enable+0x28a/0x330 fs/quota/dquot.c:2490 ext4_quota_enable fs/ext4/super.c:6137 [inline] ext4_enable_quotas+0x5d7/0x960 fs/ext4/super.c:6163 ext4_fill_
ot.c:2490 ext4_quota_enable fs/ext4/super.c:6137 [inline] ext4_enable_quotas+0x5d7/0x960 fs/ext4/super.c:6163 ext4_fill_super+0xa7c9/0xdc00 fs/ext4/super.c:4754 mount_bdev+0x2e9/0x3b0 fs/super.c:1158 mount_fs+0x4b/0x1e4 fs/super.c:1261 [...] ================================================================== Above issue may happen as follows: ------------------------------------- ext4_fill_super ext4_enable_quotas ext4_quota_enable ext4_iget __ext4_iget ext4_ext_check_inode ext4_ext_check __ext4_ext_check ext4_valid_extent_entries Check for overlapping extents does't take effect dquot_enable vfs_load_quota_inode v2_check_quota_file v2_read_header ext4_quota_read ext4_bread ext4_getblk ext4_ma
fect dquot_enable vfs_load_quota_inode v2_check_quota_file v2_read_header ext4_quota_read ext4_bread ext4_getblk ext4_map_blocks ext4_ext_map_blocks ext4_find_extent ext4_cache_extents ext4_es_cache_extent ext4_es_cache_extent __es_tree_search ext4_es_end BUG_ON(es->es_lblk + es->es_len < es->es_lblk) The error ext4 extents is as follows: 0af3 0300 0400 0000 00000000 extent_header 00000000 0100 0000 12000000 extent1 00000000 0100 0000 18000000 extent2 02000000 0400 0000 14000000 extent3 In the ext4_valid_extent_entries function, if prev is 0, no error is returned even if lblock<=prev. This was intended to skip the check on the first extent, but in the error image above, prev=0+1-1=0 when che
lock<=prev. This was intended to skip the check on the first extent, but in the error image above, prev=0+1-1=0 when checking the second extent, so even though lblock<=prev, the function does not return an error. As a result, bug_ON occurs in __es_tree_search and the system panics. To solve this problem, we only need to check that: 1. The lblock of the first extent is not less than 0. 2. The lblock of the next extent is not less than the next block of the previous extent. The same applies to extent_idx. References: - https://git.kernel.org/stable/c/d0083459e2b6b07ebd78bea2fe684a19cc0f3d0f - https://git.kernel.org/stable/c/4fd58b5cf118d2d9038a0b8c9cc0e43096297686 - https://git.kernel.org/stab
e684a19cc0f3d0f - https://git.kernel.org/stable/c/4fd58b5cf118d2d9038a0b8c9cc0e43096297686 - https://git.kernel.org/stable/c/3c617827cd51018bc377bd2954e176920ddbcfad - https://git.kernel.org/stable/c/59cf2fabbfe76de29d88dd7ae69858a25735b59f - https://git.kernel.org/stable/c/ea6ea18b3ab0c0d7fefffb3c4d27df758b1c790a - https://git.kernel.org/stable/c/d36f6ed761b53933b0b4126486c10d3da7751e7f
CVE ID: CVE-2022-49410 State: PUBLISHED Published: 2025-02-26T02:12:33.124Z Last Updated: 2025-10-01T19:46:50.147Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: Fix potential double free in create_var_ref() In create_var_ref(), init_var_ref() is called to initialize the fields of variable ref_field, which is allocated in the previous function call to create_hist_field(). Function init_var_ref() allocates the corresponding fields such as ref_field->system, but frees these fields when the function encounters an error. The caller later calls destroy_hist_field() to conduct error handling, which frees the fields and the v
unters an error. The caller later calls destroy_hist_field() to conduct error handling, which frees the fields and the variable itself. This results in double free of the fields which are already freed in the previous function. Fix this by storing NULL to the corresponding fields when they are freed in init_var_ref(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f8b383f83cb573152c577eca1ef101e89995b72a - https://git.kernel.org/stable/c/c27f744ceefadc7bbeb14233b6abc150ced617d2 - https://git.kernel.org/stable/c/058cb6d86b9789377216c936506b346aaa1eb581 - https://git.kernel.org/stable/c/37443b3508b8cce6832f8d25cb4550b2f7801f50 - https://git.ker
9377216c936506b346aaa1eb581 - https://git.kernel.org/stable/c/37443b3508b8cce6832f8d25cb4550b2f7801f50 - https://git.kernel.org/stable/c/4fdfb15e08598711dbf50daf56a33965232daf0e - https://git.kernel.org/stable/c/bd83ff3bbfb003832481c9bff999d12385f396ae - https://git.kernel.org/stable/c/99696a2592bca641eb88cc9a80c90e591afebd0f
CVE ID: CVE-2022-49411 State: PUBLISHED Published: 2025-02-26T02:12:33.628Z Last Updated: 2025-05-04T08:37:06.106Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bfq: Make sure bfqg for which we are queueing requests is online Bios queued into BFQ IO scheduler can be associated with a cgroup that was already offlined. This may then cause insertion of this bfq_group into a service tree. But this bfq_group will get freed as soon as last bio associated with it is completed leading to use after free issues for service tree users. Fix the problem by making sure we always operate on online bfq_group. If the bfq_group associated with
vice tree users. Fix the problem by making sure we always operate on online bfq_group. If the bfq_group associated with the bio is not online, we pick the first online parent. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/ccddf8cd411c1800863ed357064e56ceffd356bb - https://git.kernel.org/stable/c/51f724bffa3403a5236597e6b75df7329c1ec6e9 - https://git.kernel.org/stable/c/6ee0868b0c3ccead5907685fcdcdd0c08dfe4b0b - https://git.kernel.org/stable/c/97bd6c56bdcb41079e488e31df56809e3b2ce628 - https://git.kernel.org/stable/c/7781c38552e6cc54ed8e9040279561340516b881 - https://git.kernel.org/stable/c/075a53b78b815301f8d3dd1ee2cd99554e34f0dd
CVE ID: CVE-2022-49412 State: PUBLISHED Published: 2025-02-26T02:12:34.114Z Last Updated: 2025-06-19T12:39:08.177Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bfq: Avoid merging queues with different parents It can happen that the parent of a bfqq changes between the moment we decide two queues are worth to merge (and set bic->stable_merge_bfqq) and the moment bfq_setup_merge() is called. This can happen e.g. because the process submitted IO for a different cgroup and thus bfqq got reparented. It can even happen that the bfqq we are merging with has parent cgroup that is already offline and going to be destroyed in which cas
appen that the bfqq we are merging with has parent cgroup that is already offline and going to be destroyed in which case the merge can lead to use-after-free issues such as: BUG: KASAN: use-after-free in __bfq_deactivate_entity+0x9cb/0xa50 Read of size 8 at addr ffff88800693c0c0 by task runc:[2:INIT]/10544 CPU: 0 PID: 10544 Comm: runc:[2:INIT] Tainted: G E 5.15.2-0.g5fb85fd-default #1 openSUSE Tumbleweed (unreleased) f1f3b891c72369aebecd2e43e4641a6358867c70 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x46/0x5a print_address_description.constprop.0+0x1f/0x140 ? __bfq_deactivate_entity+0x9cb
l Trace: <IRQ> dump_stack_lvl+0x46/0x5a print_address_description.constprop.0+0x1f/0x140 ? __bfq_deactivate_entity+0x9cb/0xa50 kasan_report.cold+0x7f/0x11b ? __bfq_deactivate_entity+0x9cb/0xa50 __bfq_deactivate_entity+0x9cb/0xa50 ? update_curr+0x32f/0x5d0 bfq_deactivate_entity+0xa0/0x1d0 bfq_del_bfqq_busy+0x28a/0x420 ? resched_curr+0x116/0x1d0 ? bfq_requeue_bfqq+0x70/0x70 ? check_preempt_wakeup+0x52b/0xbc0 __bfq_bfqq_expire+0x1a2/0x270 bfq_bfqq_expire+0xd16/0x2160 ? try_to_wake_up+0x4ee/0x1260 ? bfq_end_wr_async_queues+0xe0/0xe0 ? _raw_write_unlock_bh+0x60/0x60 ? _raw_spin_lock_irq+0x81/0xe0 bfq_idle_slice_timer+0x109/0x280 ? bfq_dispatch_request+0x4870/0x4870 __hrtimer_run_queues+0x37d/0x70
lock_irq+0x81/0xe0 bfq_idle_slice_timer+0x109/0x280 ? bfq_dispatch_request+0x4870/0x4870 __hrtimer_run_queues+0x37d/0x700 ? enqueue_hrtimer+0x1b0/0x1b0 ? kvm_clock_get_cycles+0xd/0x10 ? ktime_get_update_offsets_now+0x6f/0x280 hrtimer_interrupt+0x2c8/0x740 Fix the problem by checking that the parent of the two bfqqs we are merging in bfq_setup_merge() is the same. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/5ee21edaed09e6b25f2c007b3f326752bc89bacf - https://git.kernel.org/stable/c/a16c65cca7d2c7ff965fdd3adc8df2156529caf1 - https://git.kernel.org/stable/c/8abc8763b11c35e03cc91d59fd0cd28d39f88ca9 - https://git.kernel.org/stable/c/c1cee4ab36ac
https://git.kernel.org/stable/c/8abc8763b11c35e03cc91d59fd0cd28d39f88ca9 - https://git.kernel.org/stable/c/c1cee4ab36acef271be9101590756ed0c0c374d9
CVE ID: CVE-2022-49413 State: PUBLISHED Published: 2025-02-26T02:12:34.604Z Last Updated: 2025-05-04T08:37:09.165Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bfq: Update cgroup information before merging bio When the process is migrated to a different cgroup (or in case of writeback just starts submitting bios associated with a different cgroup) bfq_merge_bio() can operate with stale cgroup information in bic. Thus the bio can be merged to a request from a different cgroup or it can result in merging of bfqqs for different cgroups or bfqqs of already dead cgroups and causing possible use-after-free issues. Fix the problem b
qqs for different cgroups or bfqqs of already dead cgroups and causing possible use-after-free issues. Fix the problem by updating cgroup information in bfq_merge_bio(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/da9f3025d595956410ceaab2bea01980d7775948 - https://git.kernel.org/stable/c/b06691af08b41dfd81052a3362514d9827b44bb1 - https://git.kernel.org/stable/c/e8821f45612f2e6d9adb9c6ba0fb4184f57692aa - https://git.kernel.org/stable/c/d9165200c5627a2cf4408eefabdf0058bdf95e1a - https://git.kernel.org/stable/c/2a1077f17169a6059992a0bbdb330e0abad1e6d9 - https://git.kernel.org/stable/c/ea591cd4eb270393810e7be01feb8fde6a34fbbe
CVE ID: CVE-2022-49414 State: PUBLISHED Published: 2025-02-26T02:12:35.083Z Last Updated: 2025-10-01T19:46:50.027Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix race condition between ext4_write and ext4_convert_inline_data Hulk Robot reported a BUG_ON: ================================================================== EXT4-fs error (device loop3): ext4_mb_generate_buddy:805: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free clusters kernel BUG at fs/ext4/ext4_jbd2.c:53! invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 25371 Comm: syz-executor.3 Not tainted 5.10.0+ #1 RIP: 0010:ext4_put_nojour
opcode: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 25371 Comm: syz-executor.3 Not tainted 5.10.0+ #1 RIP: 0010:ext4_put_nojournal fs/ext4/ext4_jbd2.c:53 [inline] RIP: 0010:__ext4_journal_stop+0x10e/0x110 fs/ext4/ext4_jbd2.c:116 [...] Call Trace: ext4_write_inline_data_end+0x59a/0x730 fs/ext4/inline.c:795 generic_perform_write+0x279/0x3c0 mm/filemap.c:3344 ext4_buffered_write_iter+0x2e3/0x3d0 fs/ext4/file.c:270 ext4_file_write_iter+0x30a/0x11c0 fs/ext4/file.c:520 do_iter_readv_writev+0x339/0x3c0 fs/read_write.c:732 do_iter_write+0x107/0x430 fs/read_write.c:861 vfs_writev fs/read_write.c:934 [inline] do_pwritev+0x1e5/0x380 fs/read_write.c:1031 [...] ==================================================