Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-50491 State: PUBLISHED Published: 2025-10-04T15:43:44.470Z Last Updated: 2025-10-04T15:43:44.470Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: coresight: cti: Fix hang in cti_disable_hw() cti_enable_hw() and cti_disable_hw() are called from an atomic context so shouldn't use runtime PM because it can result in a sleep when communicating with firmware. Since commit 3c6656337852 ("Revert "firmware: arm_scmi: Add clock management to the SCMI power domain""), this causes a hang on Juno when running the Perf Coresight tests or running this command: perf record -e cs_etm//u -- ls This was also missed until the reve
ing the Perf Coresight tests or running this command: perf record -e cs_etm//u -- ls This was also missed until the revert commit because pm_runtime_put() was called with the wrong device until commit 692c9a499b28 ("coresight: cti: Correct the parameter for pm_runtime_put") With lock and scheduler debugging enabled the following is output: coresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent: 20020000.cti BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs las
reempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948 softirqs last enabled at (0): [<ffff80000822b394>] copy_process+0xa0c/0x1948 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022 Call trace: dump_backtrace+0x134/0x140 show_stack+0x20/0x58 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 __might_resched+0x180/0x228 __might_sle
e+0x134/0x140 show_stack+0x20/0x58 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 __might_resched+0x180/0x228 __might_sleep+0x50/0x88 __pm_runtime_resume+0xac/0xb0 cti_enable+0x44/0x120 coresight_control_assoc_ectdev+0xc0/0x150 coresight_enable_path+0xb4/0x288 etm_event_start+0x138/0x170 etm_event_add+0x48/0x70 event_sched_in.isra.122+0xb4/0x280 merge_sched_in+0x1fc/0x3d0 visit_groups_merge.constprop.137+0x16c/0x4b0 ctx_sched_in+0x114/0x1f0 perf_event_sched_in+0x60/0x90 ctx_resched+0x68/0xb0 perf_event_exec+0x138/0x508 begin_new_exec+0x52c/0xd40 load_elf_binary+0x6b8/0x17d0 bprm_execve+0x360/0x7f8 do_execveat_common.isra.47+0x218/0x238 __arm64_sys_execve+0x48/0x60 invoke_syscall+0x4c/0x110 el
bprm_execve+0x360/0x7f8 do_execveat_common.isra.47+0x218/0x238 __arm64_sys_execve+0x48/0x60 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.4+0xfc/0x120 do_el0_svc+0x34/0xc0 el0_svc+0x40/0x98 el0t_64_sync_handler+0x98/0xc0 el0t_64_sync+0x170/0x174 Fix the issue by removing the runtime PM calls completely. They are not needed here because it must have already been done when building the path for a trace. [ Fix build warnings ] References: - https://git.kernel.org/stable/c/e33ce54cef5d429430e3b1ae5c8ee4f4103c4fdc - https://git.kernel.org/stable/c/4c365a0c21aaf2b8fcc88de8dc298803288f61ac - https://git.kernel.org/stable/c/c51cfba50df8b9e16bfe0e6d4f2f252a4a10063d - https://git.kernel.org/stabl
298803288f61ac - https://git.kernel.org/stable/c/c51cfba50df8b9e16bfe0e6d4f2f252a4a10063d - https://git.kernel.org/stable/c/6746eae4bbaddcc16b40efb33dab79210828b3ce
CVE ID: CVE-2022-50492 State: PUBLISHED Published: 2025-10-04T15:43:45.204Z Last Updated: 2025-10-04T15:43:45.204Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/msm: fix use-after-free on probe deferral The bridge counter was never reset when tearing down the DRM device so that stale pointers to deallocated structures would be accessed on the next tear down (e.g. after a second late bind deferral). Given enough bridges and a few probe deferrals this could currently also lead to data beyond the bridge array being corrupted. Patchwork: https://patchwork.freedesktop.org/patch/502665/ References: - https://git.kernel.org/stabl
y being corrupted. Patchwork: https://patchwork.freedesktop.org/patch/502665/ References: - https://git.kernel.org/stable/c/0a30a47741b6df1f9555a0fac6aebb7e8c363bad - https://git.kernel.org/stable/c/6808abdb33bf90330e70a687d29f038507e06ebb
CVE ID: CVE-2022-50493 State: PUBLISHED Published: 2025-10-04T15:43:45.895Z Last Updated: 2025-10-04T15:43:45.895Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix crash when I/O abort times out While performing CPU hotplug, a crash with the following stack was seen: Call Trace: qla24xx_process_response_queue+0x42a/0x970 [qla2xxx] qla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx] qla_nvme_post_cmd+0x166/0x240 [qla2xxx] nvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc] blk_mq_dispatch_rq_list+0x17b/0x610 __blk_mq_sched_dispatch_requests+0xb0/0x140 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x35/0x9
x610 __blk_mq_sched_dispatch_requests+0xb0/0x140 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x35/0x90 __blk_mq_delay_run_hw_queue+0x161/0x180 blk_execute_rq+0xbe/0x160 __nvme_submit_sync_cmd+0x16f/0x220 [nvme_core] nvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics] nvme_fc_create_association.cold+0x50/0x3dc [nvme_fc] nvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc] process_one_work+0x1e8/0x3c0 On abort timeout, completion was called without checking if the I/O was already completed. Verify that I/O and abort request are indeed outstanding before attempting completion. References: - https://git.kernel.org/stable/c/d3871af13aa03fbbe7fbb812eaf140501229a72e - https://git.kernel
completion. References: - https://git.kernel.org/stable/c/d3871af13aa03fbbe7fbb812eaf140501229a72e - https://git.kernel.org/stable/c/cb4dff498468b62e8c520568559b3a9007e104d7 - https://git.kernel.org/stable/c/05382ed9142cf8a8a3fb662224477eecc415778b - https://git.kernel.org/stable/c/68ad83188d782b2ecef2e41ac245d27e0710fe8e
CVE ID: CVE-2022-50494 State: PUBLISHED Published: 2025-10-04T15:43:46.562Z Last Updated: 2025-10-04T15:43:46.562Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash When CPU 0 is offline and intel_powerclamp is used to inject idle, it generates kernel BUG: BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687 caller is debug_smp_processor_id+0x17/0x20 CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57 Call Trace: <TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 check_preemption_disabled+0xdd/0xe0 debug_smp_processor_i
ll Trace: <TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 check_preemption_disabled+0xdd/0xe0 debug_smp_processor_id+0x17/0x20 powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp] ... ... Here CPU 0 is the control CPU by default and changed to the current CPU, if CPU 0 offlined. This check has to be performed under cpus_read_lock(), hence the above warning. Use get_cpu() instead of smp_processor_id() to avoid this BUG. [ rjw: Subject edits ] References: - https://git.kernel.org/stable/c/3e799e815097febbcb81b472285be824f5d089f9 - https://git.kernel.org/stable/c/0f91f66c568b316b19cb042cf50584467b3bdff4 - https://git.kernel.org/stable/c/6904727db0eb62fb0c2dce1cf331c341d97ee4b7 - https://g
c568b316b19cb042cf50584467b3bdff4 - https://git.kernel.org/stable/c/6904727db0eb62fb0c2dce1cf331c341d97ee4b7 - https://git.kernel.org/stable/c/5a646c38f648185ee2c62f2a19da3c6f04e27612 - https://git.kernel.org/stable/c/513943bf879d45005213e6f5cfb7d9e9943f589f - https://git.kernel.org/stable/c/5614908434451aafbf9b24cb5247cf1d21269f76 - https://git.kernel.org/stable/c/6e2a347b304224b2aeb1c0ea000d1cf8a02cc592 - https://git.kernel.org/stable/c/418fae0700e85a498062424f8656435c32cdb200 - https://git.kernel.org/stable/c/68b99e94a4a2db6ba9b31fe0485e057b9354a640
CVE ID: CVE-2022-50495 State: REJECTED Published: 2025-10-04T15:43:47.266Z Last Updated: 2025-10-05T09:31:38.372Z Description: No description available.
CVE ID: CVE-2022-50496 State: PUBLISHED Published: 2025-10-04T15:43:47.948Z Last Updated: 2025-10-04T15:43:47.948Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm cache: Fix UAF in destroy() Dm_cache also has the same UAF problem when dm_resume() and dm_destroy() are concurrent. Therefore, cancelling timer again in destroy(). References: - https://git.kernel.org/stable/c/034cbc8d3b47a56acd89453c29632a9c117de09d - https://git.kernel.org/stable/c/993406104d2b28fe470126a062ad37a1e21e792e - https://git.kernel.org/stable/c/4d20032dd90664de09f2902a7ea49ae2f7771746 - https://git.kernel.org/stable/c/2f097dfac7579fd84ff98eb1d3acd41d53
g/stable/c/4d20032dd90664de09f2902a7ea49ae2f7771746 - https://git.kernel.org/stable/c/2f097dfac7579fd84ff98eb1d3acd41d53a485f3 - https://git.kernel.org/stable/c/2b17026685a270b2beaf1cdd9857fcedd3505c7e - https://git.kernel.org/stable/c/d2a0b298ebf83ab6236f66788a3541e91ce75a70 - https://git.kernel.org/stable/c/6ac4f36910764cb510bafc4c3768544f86ca48ca - https://git.kernel.org/stable/c/6a3e412c2ab131c54945327a7676b006f000a209 - https://git.kernel.org/stable/c/6a459d8edbdbe7b24db42a5a9f21e6aa9e00c2aa
CVE ID: CVE-2022-50497 State: PUBLISHED Published: 2025-10-04T15:43:48.656Z Last Updated: 2025-10-04T15:43:48.656Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: binfmt_misc: fix shift-out-of-bounds in check_special_flags UBSAN reported a shift-out-of-bounds warning: left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106 ubsan_epilogue+0xa/0x44 lib/ubsan.c:151 __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322 check_special_flags fs/binfmt_misc.c:241 [inline] create_entry fs/binfmt_misc.c:456 [inline]
0x1e7/0x208 lib/ubsan.c:322 check_special_flags fs/binfmt_misc.c:241 [inline] create_entry fs/binfmt_misc.c:456 [inline] bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654 vfs_write+0x11e/0x580 fs/read_write.c:582 ksys_write+0xcf/0x120 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4194e1 Since the type of Node's flags is unsigned long, we should define these macros with same type too. References: - https://git.kernel.org/stable/c/0f1a48994b3e516d5c7fd5d12204fdba7a604771 - https://git.kernel.org/stable/c/ea6145370be8016755c43aca799815fc4b8c88b1 - https://git.kernel.
c7fd5d12204fdba7a604771 - https://git.kernel.org/stable/c/ea6145370be8016755c43aca799815fc4b8c88b1 - https://git.kernel.org/stable/c/97382a2639b1cd9631f6069061e9d7062cd2b098 - https://git.kernel.org/stable/c/419b808504c26b3e3342365f34ccd0843e09a7f8 - https://git.kernel.org/stable/c/dcbc51d31d0afbd45e830e3cf565a7b3ca7bf0d8 - https://git.kernel.org/stable/c/88cea1676a09f7c45a1438153a126610c33b1590 - https://git.kernel.org/stable/c/a651bb5ff997b9f02662bcdef3d8b4e6f0d79656 - https://git.kernel.org/stable/c/a91123d4bda463469f68f0427adabf8108001f94 - https://git.kernel.org/stable/c/6a46bf558803dd2b959ca7435a5c143efe837217
CVE ID: CVE-2022-50498 State: PUBLISHED Published: 2025-10-04T15:43:49.383Z Last Updated: 2025-10-04T15:43:49.383Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: eth: alx: take rtnl_lock on resume Zbynek reports that alx trips an rtnl assertion on resume: RTNL: assertion failed at net/core/dev.c (2891) RIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0 Call Trace: <TASK> __alx_open+0x230/0x570 [alx] alx_resume+0x54/0x80 [alx] ? pci_legacy_resume+0x80/0x80 dpm_run_callback+0x4a/0x150 device_resume+0x8b/0x190 async_resume+0x19/0x30 async_run_entry_fn+0x30/0x130 process_one_work+0x1e5/0x3b0 indeed the driver does not hold rtnl_loc
ync_resume+0x19/0x30 async_run_entry_fn+0x30/0x130 process_one_work+0x1e5/0x3b0 indeed the driver does not hold rtnl_lock during its internal close and re-open functions during suspend/resume. Note that this is not a huge bug as the driver implements its own locking, and does not implement changing the number of queues, but we need to silence the splat. References: - https://git.kernel.org/stable/c/6f1991a940b90753b34570f093a21dba366e8cc0 - https://git.kernel.org/stable/c/a845a0c4bdece2c0073ecea2fca7c4d5f0550f78 - https://git.kernel.org/stable/c/c0323c0fd07804d5874699e93f935cda0d989c67 - https://git.kernel.org/stable/c/6ad1c94e1e7e374d88f0cfd77936dddb8339aaba
CVE ID: CVE-2022-50499 State: PUBLISHED Published: 2025-10-04T15:43:50.064Z Last Updated: 2025-10-04T15:43:50.064Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: Fix double free in dvb_register_device() In function dvb_register_device() -> dvb_register_media_device() -> dvb_create_media_entity(), dvb->entity is allocated and initialized. If the initialization fails, it frees the dvb->entity, and return an error code. The caller takes the error code and handles the error by calling dvb_media_device_free(), which unregisters the entity and frees the field again if it is not NULL. As dvb->entity may not NULLed in
vice_free(), which unregisters the entity and frees the field again if it is not NULL. As dvb->entity may not NULLed in dvb_create_media_entity() when the allocation of dvbdev->pad fails, a double free may occur. This may also cause an Use After free in media_device_unregister_entity(). Fix this by storing NULL to dvb->entity when it is freed. References: - https://git.kernel.org/stable/c/0588b12c418c3e4f927ced11f27b02ef4a5bfb07 - https://git.kernel.org/stable/c/e9a78485b658361fab6a5547377be6c1af6f1b3d - https://git.kernel.org/stable/c/70bc51303871159796b55ba1a8f16637b46c2511 - https://git.kernel.org/stable/c/b21f62b49ee9c3e0216d685d9cfd6003e5727271 - https://git.kernel.org/stable/c/7dd5a68c
11 - https://git.kernel.org/stable/c/b21f62b49ee9c3e0216d685d9cfd6003e5727271 - https://git.kernel.org/stable/c/7dd5a68cdbbbe7fc67ba701cb52ba10d8ba149f8 - https://git.kernel.org/stable/c/acf984a3718c2458eb9e08b6714490a04f213c58 - https://git.kernel.org/stable/c/772892b29ac50c2c5e918fc80104aa6ede81d837 - https://git.kernel.org/stable/c/123eddf92a114e03919942641d2c2b1f4ca56ea6 - https://git.kernel.org/stable/c/6b0d0477fce747d4137aa65856318b55fba72198
CVE ID: CVE-2022-50500 State: PUBLISHED Published: 2025-10-04T15:43:50.792Z Last Updated: 2025-10-04T15:43:50.792Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netdevsim: fix memory leak in nsim_drv_probe() when nsim_dev_resources_register() failed If some items in nsim_dev_resources_register() fail, memory leak will occur. The following is the memory leak information. unreferenced object 0xffff888074c02600 (size 128): comm "echo", pid 8159, jiffies 4294945184 (age 493.530s) hex dump (first 32 bytes): 40 47 ea 89 ff ff ff ff 01 00 00 00 00 00 00 00 @G.............. ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff .............
ea 89 ff ff ff ff 01 00 00 00 00 00 00 00 @G.............. ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace: [<0000000011a31c98>] kmalloc_trace+0x22/0x60 [<0000000027384c69>] devl_resource_register+0x144/0x4e0 [<00000000a16db248>] nsim_drv_probe+0x37a/0x1260 [<000000007d1f448c>] really_probe+0x20b/0xb10 [<00000000c416848a>] __driver_probe_device+0x1b3/0x4a0 [<00000000077e0351>] driver_probe_device+0x49/0x140 [<0000000054f2465a>] __device_attach_driver+0x18c/0x2a0 [<000000008538f359>] bus_for_each_drv+0x151/0x1d0 [<0000000038e09747>] __device_attach+0x1c9/0x4e0 [<00000000dd86e533>] bus_probe_device+0x1d5/0x280 [<00000000839bea35>] device_add+0xae0/0x1cb0 [<000000009c
+0x1c9/0x4e0 [<00000000dd86e533>] bus_probe_device+0x1d5/0x280 [<00000000839bea35>] device_add+0xae0/0x1cb0 [<000000009c2abf46>] new_device_store+0x3b6/0x5f0 [<00000000fb823d7f>] bus_attr_store+0x72/0xa0 [<000000007acc4295>] sysfs_kf_write+0x106/0x160 [<000000005f50cb4d>] kernfs_fop_write_iter+0x3a8/0x5a0 [<0000000075eb41bf>] vfs_write+0x8f0/0xc80 References: - https://git.kernel.org/stable/c/7c4957fe40e2a628b7cceaf4c9bfb5b701774d05 - https://git.kernel.org/stable/c/6b1da9f7126f05e857da6db24c6a04aa7974d644
CVE ID: CVE-2022-50501 State: PUBLISHED Published: 2025-10-04T15:43:51.498Z Last Updated: 2025-10-04T15:43:51.498Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: coda: Add check for dcoda_iram_alloc As the coda_iram_alloc may return NULL pointer, it should be better to check the return value in order to avoid NULL poineter dereference, same as the others. References: - https://git.kernel.org/stable/c/5688d33aa293dfa122d66bef9c0258ddf7ef11e7 - https://git.kernel.org/stable/c/2c6887d5a29024bada6928d1d0959c9990401384 - https://git.kernel.org/stable/c/45f57abaee136a1e39d2b04443a1bd5311ba7d94 - https://git.kernel.org/stable/c
c9990401384 - https://git.kernel.org/stable/c/45f57abaee136a1e39d2b04443a1bd5311ba7d94 - https://git.kernel.org/stable/c/2b436f1410245412ea5e4c356a175a928d73eed3 - https://git.kernel.org/stable/c/35ddd00b36589cf948875b825eedaab1aefd5ad5 - https://git.kernel.org/stable/c/b99872178e7473f21904fdeea38109275aad8ae8 - https://git.kernel.org/stable/c/532417dc98cb9c1185ada4ea4e7ccf965c06bcb5 - https://git.kernel.org/stable/c/05f165ded4a7baec31b65aba88e2cd1fb9b91db2 - https://git.kernel.org/stable/c/6b8082238fb8bb20f67e46388123e67a5bbc558d
CVE ID: CVE-2022-50502 State: REJECTED Published: 2025-10-04T15:43:52.178Z Last Updated: 2025-10-10T16:05:13.216Z Description: No description available.
CVE ID: CVE-2022-50503 State: PUBLISHED Published: 2025-10-04T15:43:52.845Z Last Updated: 2025-10-04T15:43:52.845Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mtd: lpddr2_nvm: Fix possible null-ptr-deref It will cause null-ptr-deref when resource_size(add_range) invoked, if platform_get_resource() returns NULL. References: - https://git.kernel.org/stable/c/4d10bd7416e8383340b5524b8d616b8ad01ef1e1 - https://git.kernel.org/stable/c/bb9ccb6121ec4140d366147aa866ceb5a21a8d3d - https://git.kernel.org/stable/c/e6aafb57d90ff2c1e18554f3a3c36247a59825ce - https://git.kernel.org/stable/c/8eb64dc5a790a529ef49ec94b3337af09dac15d3 - https
afb57d90ff2c1e18554f3a3c36247a59825ce - https://git.kernel.org/stable/c/8eb64dc5a790a529ef49ec94b3337af09dac15d3 - https://git.kernel.org/stable/c/0919982a1744346269320615615c7deb14106661 - https://git.kernel.org/stable/c/e0d3e46ac6669cdf1b99bc7b7d92f1221b9a1ff2 - https://git.kernel.org/stable/c/f82f63b3911f1b2da68a14d9c4babf3b55feca55 - https://git.kernel.org/stable/c/c4cc41e94d8357f5f02b8ef40257bb23931d8438 - https://git.kernel.org/stable/c/6bdd45d795adf9e73b38ced5e7f750cd199499ff
CVE ID: CVE-2022-50504 State: PUBLISHED Published: 2025-10-04T15:43:53.523Z Last Updated: 2025-10-04T15:43:53.523Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powerpc/rtas: avoid scheduling in rtas_os_term() It's unsafe to use rtas_busy_delay() to handle a busy status from the ibm,os-term RTAS function in rtas_os_term(): Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0 preempt_count: 2, expected: 0 CPU: 7 PID: 1 Comm: swapper/0 Tainted: G D 6.0.0
1, non_block: 0, pid: 1, name: swapper/0 preempt_count: 2, expected: 0 CPU: 7 PID: 1 Comm: swapper/0 Tainted: G D 6.0.0-rc5-02182-gf8553a572277-dirty #9 Call Trace: [c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (unreliable) [c000000007b8f040] [c0000000002440e4] __might_resched+0x394/0x3c0 [c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0 [c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4 [c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68 [c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+0x34/0x50 [c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0 [c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call
0007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0 [c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0 [c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0 [c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420 [c000000007b8f480] [c0000000001e586c] make_task_dead+0xdc/0x200 Use rtas_busy_delay_time() instead, which signals without side effects whether to attempt the ibm,os-term RTAS call again. References: - https://git.kernel.org/stable/c/f413135b337c4e90c1e593c6613f8717e17bc724 - https://git.kernel.org/stable/c/4768935b8cc2d2afeb7956292df0f6e2c49ca0a5 - https://git.kernel.org/stable/c/ffa991a003abb4f8cb9e5004646bfe2d9a46912c - https://git.kernel.o
7956292df0f6e2c49ca0a5 - https://git.kernel.org/stable/c/ffa991a003abb4f8cb9e5004646bfe2d9a46912c - https://git.kernel.org/stable/c/515959eb49e6d218a46979d66f36fdef329ac7d2 - https://git.kernel.org/stable/c/6f7e2fcab73372a371ab4017cbedf7a71f4f9b40 - https://git.kernel.org/stable/c/7280fdb80bf0fe35d9b799fc7009f2cbe0a397d7 - https://git.kernel.org/stable/c/bed48651c87bef59ea1a9d6dbc381bcbc452f4ff - https://git.kernel.org/stable/c/482d990a5dd1027ee0b70a8a570d56749cac8103 - https://git.kernel.org/stable/c/6c606e57eecc37d6b36d732b1ff7e55b7dc32dd4
CVE ID: CVE-2022-50505 State: PUBLISHED Published: 2025-10-04T15:43:54.265Z Last Updated: 2025-10-04T15:43:54.265Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix pci device refcount leak in ppr_notifier() As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). So call it before returning from ppr_notifier() to avoid refcount leak. References: - https://git.kernel.org/stable/c/bdb2113dd8f17a3cc84a2b4be4968a849f69ec72 - https://git.kernel.org/stable/c/efd50c65fd1cdef63eb58825f3fe7
el.org/stable/c/bdb2113dd8f17a3cc84a2b4be4968a849f69ec72 - https://git.kernel.org/stable/c/efd50c65fd1cdef63eb58825f3fe72496443764c - https://git.kernel.org/stable/c/8581ec1feb895ff596fe3d326d9ba320083290aa - https://git.kernel.org/stable/c/03f51c72997559e73b327608f0cccfded715c9a0 - https://git.kernel.org/stable/c/6e501b3fd7a2e1c4372d72bc70717aaca2beb8a5 - https://git.kernel.org/stable/c/902cc2507091a81643502d8ceb0e2f105e902518 - https://git.kernel.org/stable/c/b0637f4bd426925f5c3a15e8f8e36190fe06bac5 - https://git.kernel.org/stable/c/6cf0981c2233f97d56938d9d61845383d6eb227c
CVE ID: CVE-2022-50506 State: PUBLISHED Published: 2025-10-04T15:43:54.955Z Last Updated: 2025-10-04T15:43:54.955Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drbd: only clone bio if we have a backing device Commit c347a787e34cb (drbd: set ->bi_bdev in drbd_req_new) moved a bio_set_dev call (which has since been removed) to "earlier", from drbd_request_prepare to drbd_req_new. The problem is that this accesses device->ldev->backing_bdev, which is not NULL-checked at this point. When we don't have an ldev (i.e. when the DRBD device is diskless), this leads to a null pointer deref. So, only allocate the private_bio if we actua
.e. when the DRBD device is diskless), this leads to a null pointer deref. So, only allocate the private_bio if we actually have a disk. This is also a small optimization, since we don't clone the bio to only to immediately free it again in the diskless case. References: - https://git.kernel.org/stable/c/05580a3bbf3cec677cb00a85dfeb21d6a9b48eaf - https://git.kernel.org/stable/c/6d42ddf7f27b6723549ee6d4c8b1b418b59bf6b5