Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-50167 State: PUBLISHED Published: 2025-06-18T11:03:20.997Z Last Updated: 2025-06-18T11:03:20.997Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: fix potential 32-bit overflow when accessing ARRAY map element If BPF array map is bigger than 4GB, element pointer calculation can overflow because both index and elem_size are u32. Fix this everywhere by forcing 64-bit multiplication. Extract this formula into separate small helper and use it consistently in various places. Speculative-preventing formula utilizing index_mask trick is left as is, but explicit u64 casts are added in both places. References: - http
ng formula utilizing index_mask trick is left as is, but explicit u64 casts are added in both places. References: - https://git.kernel.org/stable/c/063e092534d4c6785228e5b1eb6e9329f66ccbe4 - https://git.kernel.org/stable/c/3c7256b880b3a5aa1895fd169a34aa4224a11862 - https://git.kernel.org/stable/c/87ac0d600943994444e24382a87aa19acc4cd3d4
CVE ID: CVE-2022-50168 State: PUBLISHED Published: 2025-06-18T11:03:21.593Z Last Updated: 2025-06-18T11:03:21.593Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf, x86: fix freeing of not-finalized bpf_prog_pack syzbot reported a few issues with bpf_prog_pack [1], [2]. This only happens with multiple subprogs. In jit_subprogs(), we first call bpf_int_jit_compile() on each sub program. And then, we call it on each sub program again. jit_data is not freed in the first call of bpf_int_jit_compile(). Similarly we don't call bpf_jit_binary_pack_finalize() in the first call of bpf_int_jit_compile(). If bpf_int_jit_compile() failed
we don't call bpf_jit_binary_pack_finalize() in the first call of bpf_int_jit_compile(). If bpf_int_jit_compile() failed for one sub program, we will call bpf_jit_binary_pack_finalize() for this sub program. However, we don't have a chance to call it for other sub programs. Then we will hit "goto out_free" in jit_subprogs(), and call bpf_jit_free on some subprograms that haven't got bpf_jit_binary_pack_finalize() yet. At this point, bpf_jit_binary_pack_free() is called and the whole 2MB page is freed erroneously. Fix this with a custom bpf_jit_free() for x86_64, which calls bpf_jit_binary_pack_finalize() if necessary. Also, with custom bpf_jit_free(), bpf_prog_aux->use_bpf_prog_pack is not n
bpf_jit_binary_pack_finalize() if necessary. Also, with custom bpf_jit_free(), bpf_prog_aux->use_bpf_prog_pack is not needed any more, remove it. [1] https://syzkaller.appspot.com/bug?extid=2f649ec6d2eea1495a8f [2] https://syzkaller.appspot.com/bug?extid=87f65c75f4a72db05445 References: - https://git.kernel.org/stable/c/f91ce608a79c0db3e72bd63c23e011a9ebc31505 - https://git.kernel.org/stable/c/60e66074812dde9cde3d99cdd3caa9e40f1a4516 - https://git.kernel.org/stable/c/1d5f82d9dd477d5c66e0214a68c3e4f308eadd6d
CVE ID: CVE-2022-50169 State: PUBLISHED Published: 2025-06-18T11:03:22.397Z Last Updated: 2025-06-18T11:03:22.397Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: wil6210: debugfs: fix info leak in wil_write_file_wmi() The simple_write_to_buffer() function will succeed if even a single byte is initialized. However, we need to initialize the whole buffer to prevent information leaks. Just use memdup_user(). References: - https://git.kernel.org/stable/c/c1216e699a1ce83ea005510844bd7508d34c6cef - https://git.kernel.org/stable/c/4615458db7793fadc6d546ac3564b36819e77a22 - https://git.kernel.org/stable/c/60c9983425167ec5073c628d
.kernel.org/stable/c/4615458db7793fadc6d546ac3564b36819e77a22 - https://git.kernel.org/stable/c/60c9983425167ec5073c628d83a6875760d18059 - https://git.kernel.org/stable/c/05ceda14ef7c73104e709c414c3680d8a59f51d4 - https://git.kernel.org/stable/c/074e865b37da55aa87baa16d68b96896f85f8adb - https://git.kernel.org/stable/c/789edc1af9c1a2293956e8534bfef3d18d629de9 - https://git.kernel.org/stable/c/67470920cd3f3cb38699b1ad23234f96bead4d21 - https://git.kernel.org/stable/c/7a4836560a6198d245d5732e26f94898b12eb760
CVE ID: CVE-2022-50170 State: PUBLISHED Published: 2025-06-18T11:03:23.031Z Last Updated: 2025-06-18T11:03:23.031Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: kunit: executor: Fix a memory leak on failure in kunit_filter_tests It's possible that memory allocation for 'filtered' will fail, but for the copy of the suite to succeed. In this case, the copy could be leaked. Properly free 'copy' in the error case for the allocation of 'filtered' failing. Note that there may also have been a similar issue in kunit_filter_subsuites, before it was removed in "kunit: flatten kunit_suite*** to kunit_suite** in .kunit_test_suites". This
_filter_subsuites, before it was removed in "kunit: flatten kunit_suite*** to kunit_suite** in .kunit_test_suites". This was reported by clang-analyzer via the kernel test robot, here: https://lore.kernel.org/all/c8073b8e-7b9e-0830-4177-87c12f16349c@intel.com/ And by smatch via Dan Carpenter and the kernel test robot: https://lore.kernel.org/all/202207101328.ASjx88yj-lkp@intel.com/ References: - https://git.kernel.org/stable/c/a8a7e3ced362b88b659ab54239990196ff975982 - https://git.kernel.org/stable/c/7d69764fa3442c7615a75c6b5c02eaa1f274bccf - https://git.kernel.org/stable/c/94681e289bf5d10c9db9db143d1a22d8717205c5
CVE ID: CVE-2022-50171 State: PUBLISHED Published: 2025-06-18T11:03:23.710Z Last Updated: 2025-06-18T11:03:23.710Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/sec - don't sleep when in softirq When kunpeng920 encryption driver is used to deencrypt and decrypt packets during the softirq, it is not allowed to use mutex lock. The kernel will report the following error: BUG: scheduling while atomic: swapper/57/0/0x00000300 Call trace: dump_backtrace+0x0/0x1e4 show_stack+0x20/0x2c dump_stack+0xd8/0x140 __schedule_bug+0x68/0x80 __schedule+0x728/0x840 schedule+0x50/0xe0 schedule_preempt_disabled+0x18/0x24 __mutex_
d8/0x140 __schedule_bug+0x68/0x80 __schedule+0x728/0x840 schedule+0x50/0xe0 schedule_preempt_disabled+0x18/0x24 __mutex_lock.constprop.0+0x594/0x5dc __mutex_lock_slowpath+0x1c/0x30 mutex_lock+0x50/0x60 sec_request_init+0x8c/0x1a0 [hisi_sec2] sec_process+0x28/0x1ac [hisi_sec2] sec_skcipher_crypto+0xf4/0x1d4 [hisi_sec2] sec_skcipher_encrypt+0x1c/0x30 [hisi_sec2] crypto_skcipher_encrypt+0x2c/0x40 crypto_authenc_encrypt+0xc8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp_output_tail+0x348/0x5c0 [esp4] esp_output+0x120/0x19c [esp4] xfrm_output_one+0x25c/0x4d4 xfrm_output_resume+0x6c/0x1fc xfrm_output+0xac/0x3c0 xfrm4_output+0
utput+0x120/0x19c [esp4] xfrm_output_one+0x25c/0x4d4 xfrm_output_resume+0x6c/0x1fc xfrm_output+0xac/0x3c0 xfrm4_output+0x64/0x130 ip_build_and_send_pkt+0x158/0x20c tcp_v4_send_synack+0xdc/0x1f0 tcp_conn_request+0x7d0/0x994 tcp_v4_conn_request+0x58/0x6c tcp_v6_conn_request+0xf0/0x100 tcp_rcv_state_process+0x1cc/0xd60 tcp_v4_do_rcv+0x10c/0x250 tcp_v4_rcv+0xfc4/0x10a4 ip_protocol_deliver_rcu+0xf4/0x200 ip_local_deliver_finish+0x58/0x70 ip_local_deliver+0x68/0x120 ip_sublist_rcv_finish+0x70/0x94 ip_list_rcv_finish.constprop.0+0x17c/0x1d0 ip_sublist_rcv+0x40/0xb0 ip_list_rcv+0x140/0x1dc __netif_receive_skb_list_core+0x154/0x28c __netif_receive_skb_list+0x120/0x1a0 netif_receive_skb_list_internal+
40/0x1dc __netif_receive_skb_list_core+0x154/0x28c __netif_receive_skb_list+0x120/0x1a0 netif_receive_skb_list_internal+0xe4/0x1f0 napi_complete_done+0x70/0x1f0 gro_cell_poll+0x9c/0xb0 napi_poll+0xcc/0x264 net_rx_action+0xd4/0x21c __do_softirq+0x130/0x358 irq_exit+0x11c/0x13c __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x78/0x2c0 el1_irq+0xb8/0x140 arch_cpu_idle+0x18/0x40 default_idle_call+0x5c/0x1c0 cpuidle_idle_call+0x174/0x1b0 do_idle+0xc8/0x160 cpu_startup_entry+0x30/0x11c secondary_start_kernel+0x158/0x1e4 softirq: huh, entered softirq 3 NET_RX 0000000093774ee4 with preempt_count 00000100, exited with fffffe00? References: - https://git.kernel.org/stable/c/16e18a8ac7c9748cf35a8d2f0ba2c
reempt_count 00000100, exited with fffffe00? References: - https://git.kernel.org/stable/c/16e18a8ac7c9748cf35a8d2f0ba2c6e8850e7568 - https://git.kernel.org/stable/c/aa495dfe71229b9034b59d8072ff0b2325ddd5ee - https://git.kernel.org/stable/c/4a461ba5b9753352f438824fdd915cba675b1733 - https://git.kernel.org/stable/c/c9be45e4c69fde36522274f04d1aa0d097ae3958 - https://git.kernel.org/stable/c/02884a4f12de11f54d4ca67a07dd1f111d96fdbd
CVE ID: CVE-2022-50172 State: PUBLISHED Published: 2025-06-18T11:03:24.408Z Last Updated: 2025-06-18T11:03:24.408Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mt76: mt76x02u: fix possible memory leak in __mt76x02u_mcu_send_msg Free the skb if mt76u_bulk_msg fails in __mt76x02u_mcu_send_msg routine. References: - https://git.kernel.org/stable/c/3ad958bc488e3ecb0207d31621c00efb86f17482 - https://git.kernel.org/stable/c/f1609c4f4a21777e081b36596224802b85052ad9 - https://git.kernel.org/stable/c/da1ab462b96c5d47a0755aec957bae3d685538c5 - https://git.kernel.org/stable/c/2f53ba46d8c97aca681adbe5098e1f84580c446d - https://git.kernel
a0755aec957bae3d685538c5 - https://git.kernel.org/stable/c/2f53ba46d8c97aca681adbe5098e1f84580c446d - https://git.kernel.org/stable/c/cffd93411575afd987788e2ec3cb8eaff70f0215
CVE ID: CVE-2022-50173 State: PUBLISHED Published: 2025-06-18T11:03:25.017Z Last Updated: 2025-06-18T11:03:25.017Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp5: Fix global state lock backoff We need to grab the lock after the early return for !hwpipe case. Otherwise, we could have hit contention yet still returned 0. Fixes an issue that the new CONFIG_DRM_DEBUG_MODESET_LOCK stuff flagged in CI: WARNING: CPU: 0 PID: 282 at drivers/gpu/drm/drm_modeset_lock.c:296 drm_modeset_lock+0xf8/0x154 Modules linked in: CPU: 0 PID: 282 Comm: kms_cursor_lega Tainted: G W 5.19.0-rc2-15930-g875cc8bc536a #1 Hardware name: Qualcomm
linked in: CPU: 0 PID: 282 Comm: kms_cursor_lega Tainted: G W 5.19.0-rc2-15930-g875cc8bc536a #1 Hardware name: Qualcomm Technologies, Inc. DB820c (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_modeset_lock+0xf8/0x154 lr : drm_atomic_get_private_obj_state+0x84/0x170 sp : ffff80000cfab6a0 x29: ffff80000cfab6a0 x28: 0000000000000000 x27: ffff000083bc4d00 x26: 0000000000000038 x25: 0000000000000000 x24: ffff80000957ca58 x23: 0000000000000000 x22: ffff000081ace080 x21: 0000000000000001 x20: ffff000081acec18 x19: ffff80000cfabb80 x18: 0000000000000038 x17: 0000000000000000 x16: 0000000000000000 x15: fffffffffffea0d0 x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 5
038 x17: 0000000000000000 x16: 0000000000000000 x15: fffffffffffea0d0 x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 5f534b434f4c5f47 x11: ffff80000a386aa8 x10: 0000000000000029 x9 : ffff80000cfab610 x8 : 0000000000000029 x7 : 0000000000000014 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff8000081ad904 x3 : 0000000000000029 x2 : ffff0000801db4c0 x1 : ffff80000cfabb80 x0 : ffff000081aceb58 Call trace: drm_modeset_lock+0xf8/0x154 drm_atomic_get_private_obj_state+0x84/0x170 mdp5_get_global_state+0x54/0x6c mdp5_pipe_release+0x2c/0xd4 mdp5_plane_atomic_check+0x2ec/0x414 drm_atomic_helper_check_planes+0xd8/0x210 drm_atomic_helper_check+0x54/0xb0 ... ---[ end trace 0000000000000000 ]--- drm
drm_atomic_helper_check_planes+0xd8/0x210 drm_atomic_helper_check+0x54/0xb0 ... ---[ end trace 0000000000000000 ]--- drm_modeset_lock attempting to lock a contended lock without backoff: drm_modeset_lock+0x148/0x154 mdp5_get_global_state+0x30/0x6c mdp5_pipe_release+0x2c/0xd4 mdp5_plane_atomic_check+0x290/0x414 drm_atomic_helper_check_planes+0xd8/0x210 drm_atomic_helper_check+0x54/0xb0 drm_atomic_check_only+0x4b0/0x8f4 drm_atomic_commit+0x68/0xe0 Patchwork: https://patchwork.freedesktop.org/patch/492701/ References: - https://git.kernel.org/stable/c/247f2934324f9a18d18df24ea4bfcc7d4631d0ef - https://git.kernel.org/stable/c/2e34d6c8180a398de6448a93df25068bf3062042 - https://git.kernel.org/stab
4bfcc7d4631d0ef - https://git.kernel.org/stable/c/2e34d6c8180a398de6448a93df25068bf3062042 - https://git.kernel.org/stable/c/bf386c955f35a0a01bef482b6035d40ff2f6cc75 - https://git.kernel.org/stable/c/f4e3a8c7e890049e7ba2b49ad0315dae841dfa55 - https://git.kernel.org/stable/c/2fdf5a54ef9376ff69149a48c5616f1141008c9f - https://git.kernel.org/stable/c/0b07f28c23ff50a7fa5dbc3f6b3b6bd53ac9fc70 - https://git.kernel.org/stable/c/92ef86ab513593c6329d04146e61f9a670e72fc5
CVE ID: CVE-2022-50174 State: PUBLISHED Published: 2025-06-18T11:03:25.675Z Last Updated: 2025-06-18T11:03:25.675Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: hinic: avoid kernel hung in hinic_get_stats64() When using hinic device as a bond slave device, and reading device stats of master bond device, the kernel may hung. The kernel panic calltrace as follows: Kernel panic - not syncing: softlockup: hung tasks Call trace: native_queued_spin_lock_slowpath+0x1ec/0x31c dev_get_stats+0x60/0xcc dev_seq_printf_stats+0x40/0x120 dev_seq_show+0x1c/0x40 seq_read_iter+0x3c8/0x4dc seq_read+0xe0/0x130 proc_reg_read+0xa8/0xe0 vfs_rea
tf_stats+0x40/0x120 dev_seq_show+0x1c/0x40 seq_read_iter+0x3c8/0x4dc seq_read+0xe0/0x130 proc_reg_read+0xa8/0xe0 vfs_read+0xb0/0x1d4 ksys_read+0x70/0xfc __arm64_sys_read+0x20/0x30 el0_svc_common+0x88/0x234 do_el0_svc+0x2c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180 And the calltrace of task that actually caused kernel hungs as follows: __switch_to+124 __schedule+548 schedule+72 schedule_timeout+348 __down_common+188 __down+24 down+104 hinic_get_stats64+44 [hinic] dev_get_stats+92 bond_get_stats+172 [bonding] dev_get_stats+92 dev_seq_printf_stats+60 dev_seq_show+24 seq_read_iter+964 seq_read+220 proc_reg_read+164 vfs_read+172 ksys_read+108 __arm64_sys_read+28 el0_sv
0 dev_seq_show+24 seq_read_iter+964 seq_read+220 proc_reg_read+164 vfs_read+172 ksys_read+108 __arm64_sys_read+28 el0_svc_common+132 do_el0_svc+40 el0_svc+24 el0_sync_handler+164 el0_sync+324 When getting device stats from bond, kernel will call bond_get_stats(). It first holds the spinlock bond->stats_lock, and then call hinic_get_stats64() to collect hinic device's stats. However, hinic_get_stats64() calls `down(&nic_dev->mgmt_lock)` to protect its critical section, which may schedule current task out. And if system is under high pressure, the task cannot be woken up immediately, which eventually triggers kernel hung panic. Since previous patch has replaced hinic_dev.tx_stats/rx_stats with
diately, which eventually triggers kernel hung panic. Since previous patch has replaced hinic_dev.tx_stats/rx_stats with local variable in hinic_get_stats64(), there is nothing need to be protected by lock, so just removing down()/up() is ok. References: - https://git.kernel.org/stable/c/e74f3097a9c713ce855cda07713393bcc23a005d - https://git.kernel.org/stable/c/693f31dc91568e61047fd2980a8235e856cd9ce8 - https://git.kernel.org/stable/c/fced5bce712122654ec8a20356342698cce104d2 - https://git.kernel.org/stable/c/3ba59bbe4f306bb6ee15753db0a40564c0eb7909 - https://git.kernel.org/stable/c/98f9fcdee35add80505b6c73f72de5f750d5c03c
CVE ID: CVE-2022-50175 State: PUBLISHED Published: 2025-06-18T11:03:26.344Z Last Updated: 2025-06-18T11:03:26.344Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: tw686x: Fix memory leak in tw686x_video_init video_device_alloc() allocates memory for vdev, when video_register_device() fails, it doesn't release the memory and leads to memory leak, call video_device_release() to fix this. References: - https://git.kernel.org/stable/c/611f86965df013d6021e6cd0d155b1734ad2cf21 - https://git.kernel.org/stable/c/0597bcf774896a002edcc7934a9cdbb932b66702 - https://git.kernel.org/stable/c/c142a7531b90c6b0f946c82d3f504b3f36a207df - h
/0597bcf774896a002edcc7934a9cdbb932b66702 - https://git.kernel.org/stable/c/c142a7531b90c6b0f946c82d3f504b3f36a207df - https://git.kernel.org/stable/c/8b412db51db24dfba22c96948580d4a12f831397 - https://git.kernel.org/stable/c/e0b212ec9d8177d6f7c404315293f6a085d6ee42
CVE ID: CVE-2022-50176 State: PUBLISHED Published: 2025-06-18T11:03:26.972Z Last Updated: 2025-06-18T11:03:26.972Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/mcde: Fix refcount leak in mcde_dsi_bind Every iteration of for_each_available_child_of_node() decrements the reference counter of the previous node. There is no decrement when break out from the loop and results in refcount leak. Add missing of_node_put() to fix this. References: - https://git.kernel.org/stable/c/87c35bbefdfa3c5edfb8c80f5c04717aaacc629d - https://git.kernel.org/stable/c/f57699a9b66ea11f000f56d1f1179059239b8690 - https://git.kernel.org/stable/c/312
acc629d - https://git.kernel.org/stable/c/f57699a9b66ea11f000f56d1f1179059239b8690 - https://git.kernel.org/stable/c/3123ae6fdd4013d24a3a4877084b14e917faae5c - https://git.kernel.org/stable/c/7214902de5b1fb2b632a7b8b3b9540e41aabab38 - https://git.kernel.org/stable/c/32c827e30bb44ae809950a9efab59e98e44d30e5 - https://git.kernel.org/stable/c/3a149169e4a2f9127022fec6ef5d71b4e804b3b9
CVE ID: CVE-2022-50177 State: PUBLISHED Published: 2025-06-18T11:03:27.588Z Last Updated: 2025-06-18T11:03:27.588Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rcutorture: Fix ksoftirqd boosting timing and iteration The RCU priority boosting can fail in two situations: 1) If (nr_cpus= > maxcpus=), which means if the total number of CPUs is higher than those brought online at boot, then torture_onoff() may later bring up CPUs that weren't online on boot. Now since rcutorture initialization only boosts the ksoftirqds of the CPUs that have been set online on boot, the CPUs later set online by torture_onoff won't benefit from the
ftirqds of the CPUs that have been set online on boot, the CPUs later set online by torture_onoff won't benefit from the boost, making RCU priority boosting fail. 2) The ksoftirqd kthreads are boosted after the creation of rcu_torture_boost() kthreads, which opens a window large enough for these rcu_torture_boost() kthreads to wait (despite running at FIFO priority) for ksoftirqds that are still running at SCHED_NORMAL priority. The issues can trigger for example with: ./kvm.sh --configs TREE01 --kconfig "CONFIG_RCU_BOOST=y" [ 34.968561] rcu-torture: !!! [ 34.968627] ------------[ cut here ]------------ [ 35.014054] WARNING: CPU: 4 PID: 114 at kernel/rcu/rcutorture.c:1979 rcu_torture_stats_p
------[ cut here ]------------ [ 35.014054] WARNING: CPU: 4 PID: 114 at kernel/rcu/rcutorture.c:1979 rcu_torture_stats_print+0x5ad/0x610 [ 35.052043] Modules linked in: [ 35.069138] CPU: 4 PID: 114 Comm: rcu_torture_sta Not tainted 5.18.0-rc1 #1 [ 35.096424] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 [ 35.154570] RIP: 0010:rcu_torture_stats_print+0x5ad/0x610 [ 35.198527] Code: 63 1b 02 00 74 02 0f 0b 48 83 3d 35 63 1b 02 00 74 02 0f 0b 48 83 3d 21 63 1b 02 00 74 02 0f 0b 48 83 3d 0d 63 1b 02 00 74 02 <0f> 0b 83 eb 01 0f 8e ba fc ff ff 0f 0b e9 b3 fc ff f82 [ 37.251049] RSP: 0000:ffffa92a0050bdf8 EFLAGS: 00010202 [ 37.277320]
b 83 eb 01 0f 8e ba fc ff ff 0f 0b e9 b3 fc ff f82 [ 37.251049] RSP: 0000:ffffa92a0050bdf8 EFLAGS: 00010202 [ 37.277320] rcu: De-offloading 8 [ 37.290367] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000001 [ 37.290387] RDX: 0000000000000000 RSI: 00000000ffffbfff RDI: 00000000ffffffff [ 37.290398] RBP: 000000000000007b R08: 0000000000000000 R09: c0000000ffffbfff [ 37.290407] R10: 000000000000002a R11: ffffa92a0050bc18 R12: ffffa92a0050be20 [ 37.290417] R13: ffffa92a0050be78 R14: 0000000000000000 R15: 000000000001bea0 [ 37.290427] FS: 0000000000000000(0000) GS:ffff96045eb00000(0000) knlGS:0000000000000000 [ 37.290448] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.290460]
ffff96045eb00000(0000) knlGS:0000000000000000 [ 37.290448] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.290460] CR2: 0000000000000000 CR3: 000000001dc0c000 CR4: 00000000000006e0 [ 37.290470] Call Trace: [ 37.295049] <TASK> [ 37.295065] ? preempt_count_add+0x63/0x90 [ 37.295095] ? _raw_spin_lock_irqsave+0x12/0x40 [ 37.295125] ? rcu_torture_stats_print+0x610/0x610 [ 37.295143] rcu_torture_stats+0x29/0x70 [ 37.295160] kthread+0xe3/0x110 [ 37.295176] ? kthread_complete_and_exit+0x20/0x20 [ 37.295193] ret_from_fork+0x22/0x30 [ 37.295218] </TASK> Fix this with boosting the ksoftirqds kthreads from the boosting hotplug callback itself and before the boosting kthreads are created. Reference
he ksoftirqds kthreads from the boosting hotplug callback itself and before the boosting kthreads are created. References: - https://git.kernel.org/stable/c/621595f771a6bd458ffbc40679e222ba5d0a7a1e - https://git.kernel.org/stable/c/8e84693621f53bf894af9905a6531e0530402145 - https://git.kernel.org/stable/c/7e7472c62c6ded322afd9d5ac8bb20a08e7c5674 - https://git.kernel.org/stable/c/3002153a91a9732a6d1d0bb95138593c7da15743
CVE ID: CVE-2022-50178 State: PUBLISHED Published: 2025-06-18T11:03:28.226Z Last Updated: 2025-06-18T11:03:28.226Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: 8852a: rfk: fix div 0 exception The DPK is a kind of RF calibration whose algorithm is to fine tune parameters and calibrate, and check the result. If the result isn't good enough, it could adjust parameters and try again. This issue is to read and show the result, but it could be a negative calibration result that causes divisor 0 and core dump. So, fix it by phy_div() that does division only if divisor isn't zero; otherwise, zero is adopted. divide error
re dump. So, fix it by phy_div() that does division only if divisor isn't zero; otherwise, zero is adopted. divide error: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 728 Comm: wpa_supplicant Not tainted 5.10.114-16019-g462a1661811a #1 <HASH:d024 28> RIP: 0010:rtw8852a_dpk+0x14ae/0x288f [rtw89_core] RSP: 0018:ffffa9bb412a7520 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 00000000000180fc RDI: ffffa141d01023c0 RBP: ffffa9bb412a76a0 R08: 0000000000001319 R09: 00000000ffffff92 R10: ffffffffc0292de3 R11: ffffffffc00d2f51 R12: 0000000000000000 R13: ffffa141d01023c0 R14: ffffffffc0290250 R15: ffffa141d0102638 FS: 00007fa99f5c2740(0000) GS:
1 R12: 0000000000000000 R13: ffffa141d01023c0 R14: ffffffffc0290250 R15: ffffa141d0102638 FS: 00007fa99f5c2740(0000) GS:ffffa142e5e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000013e8e010 CR3: 0000000110d2c000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: rtw89_core_sta_add+0x95/0x9c [rtw89_core <HASH:d239 29>] rtw89_ops_sta_state+0x5d/0x108 [rtw89_core <HASH:d239 29>] drv_sta_state+0x115/0x66f [mac80211 <HASH:81fe 30>] sta_info_insert_rcu+0x45c/0x713 [mac80211 <HASH:81fe 30>] sta_info_insert+0xf/0x1b [mac80211 <HASH:81fe 30>] ieee80211_prep_connection+0x9d6/0xb0c [mac80211 <HASH:81fe 30>] ieee80211_mgd_auth+0x2aa/0x352 [mac80211 <HASH:81fe
30>] ieee80211_prep_connection+0x9d6/0xb0c [mac80211 <HASH:81fe 30>] ieee80211_mgd_auth+0x2aa/0x352 [mac80211 <HASH:81fe 30>] cfg80211_mlme_auth+0x160/0x1f6 [cfg80211 <HASH:00cd 31>] nl80211_authenticate+0x2e5/0x306 [cfg80211 <HASH:00cd 31>] genl_rcv_msg+0x371/0x3a1 ? nl80211_stop_sched_scan+0xe5/0xe5 [cfg80211 <HASH:00cd 31>] ? genl_rcv+0x36/0x36 netlink_rcv_skb+0x8a/0xf9 genl_rcv+0x28/0x36 netlink_unicast+0x27b/0x3a0 netlink_sendmsg+0x2aa/0x469 sock_sendmsg_nosec+0x49/0x4d ____sys_sendmsg+0xe5/0x213 __sys_sendmsg+0xec/0x157 ? syscall_enter_from_user_mode+0xd7/0x116 do_syscall_64+0x43/0x55 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fa99f6e689b References: - https://git.kernel.org