Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
H_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/2604afd65043e8f9d4be036cb1242adf6b5723cf - https://git.kernel.org/stable/c/f432a1621f049bb207e78363d9d0e3c6fa2da5db
CVE ID: CVE-2024-53072 State: PUBLISHED Published: 2024-11-19T17:22:38.861Z Last Updated: 2025-11-03T22:29:02.256Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH ret
x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/a50863dd1f92d43c975ab2ecc3476617fe98a66e - https://git.kernel.org/stable/c/7a3ed3f125292bc3398e04d10108124250892e3f - https://git.kernel.org/stable/c/67ff30e24a0466bdd5be1d0b84385ec3c85fdacd - https://git.kernel.org/stable/c/bceec87a73804bb4c33b9a6c96e2d27cd893a801
CVE ID: CVE-2024-53073 State: PUBLISHED Published: 2024-11-19T17:31:38.040Z Last Updated: 2025-05-04T13:00:16.355Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: NFSD: Never decrement pending_async_copies on error The error flow in nfsd4_copy() calls cleanup_async_copy(), which already decrements nn->pending_async_copies. References: - https://git.kernel.org/stable/c/ed98d26021db0fe62c327aa9f5e57a90bff3fa94 - https://git.kernel.org/stable/c/9467c49437e948c541569007cd412d577942e635 - https://git.kernel.org/stable/c/949ee5d44d1fd95119b29b3382a933cdc617bf9e - https://git.kernel.org/stable/c/fb79d68a36e21960341ccab07d1ac06d93830321
le/c/949ee5d44d1fd95119b29b3382a933cdc617bf9e - https://git.kernel.org/stable/c/fb79d68a36e21960341ccab07d1ac06d93830321 - https://git.kernel.org/stable/c/1421883aa30c5d26bc3370e2d19cb350f0d5ca28 - https://git.kernel.org/stable/c/8286f8b622990194207df9ab852e0f87c60d35e9
CVE ID: CVE-2024-53074 State: PUBLISHED Published: 2024-11-19T17:31:39.010Z Last Updated: 2025-10-01T20:17:15.909Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/70ddf9ce1894c48dbbf10b0de51a95e4fb3dd376 - https://git.kernel.org/stable/c/3ed092997a004d68a3a5b0eeb94e7
el.org/stable/c/70ddf9ce1894c48dbbf10b0de51a95e4fb3dd376 - https://git.kernel.org/stable/c/3ed092997a004d68a3a5b0eeb94e71b69839d0f7
CVE ID: CVE-2024-53075 State: PUBLISHED Published: 2024-11-19T17:31:39.625Z Last Updated: 2025-05-04T09:52:19.201Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' c
we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case. References: - https://git.kernel.org/stable/c/80aec5a855106c668b5978c48e789f010198b832 - https://git.kernel.org/stable/c/303846a3dc275e35fbb556d72f1e356ba669e4f8 - https://git.kernel.org/stable/c/37233169a6ea912020c572f870075a63293b786a
CVE ID: CVE-2024-53076 State: PUBLISHED Published: 2024-11-19T17:31:40.349Z Last Updated: 2025-10-01T20:17:15.740Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0. Additional Analyst Notes: - CISA ADP Vulnrichment: References:
h will cause memory leaks. Fix it by checking if i >= 0. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/62c11896683129790b8f5ab6eb7e695818b0b723 - https://git.kernel.org/stable/c/b304362ce836968b803e5d4c5f84dcb51a7bf0f2 - https://git.kernel.org/stable/c/369f05688911b05216cfcd6ca74473bec87948d7
CVE ID: CVE-2024-53077 State: PUBLISHED Published: 2024-11-19T17:31:40.974Z Last Updated: 2025-10-01T20:17:15.551Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/36b7f5a4f300d038270324640ff7c1399245159d - https://git.kernel.org/stable/c/63a81588cd2025e75fbaf30b65930b76825c456f
CVE ID: CVE-2024-53078 State: PUBLISHED Published: 2024-11-19T17:31:41.703Z Last Updated: 2025-10-01T20:17:15.225Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/6d6c005855b97b8caf6039c1774745ee74c91fa6 - https://git.kernel.org/stable/c/a85df8c7b5ee2d3d4823befada42c5c41aff4cb0
CVE ID: CVE-2024-53079 State: PUBLISHED Published: 2024-11-19T17:45:09.914Z Last Updated: 2025-10-01T20:17:15.047Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, "Bad page state"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixi
's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now ca
ue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has
when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 ("mm: thp: make deferred split shrinker memcg aware"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 ("mm: split underused THPs") avoids splitt
on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 ("mm: split underused THPs") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting "from" memcg's list, l
mcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting "from" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount
ommit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 ("mm: thp: don't need care deferred split queue in memcg charge move path"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.
r backports, but they can fix cornercases. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/fc4951c3e3358dd82ea508e893695b916c813f17 - https://git.kernel.org/stable/c/afb1352d06b1b6b2cfd1f901c766a430c87078b3 - https://git.kernel.org/stable/c/f8f931bba0f92052cf842b7e30917b1afcc77d5a
CVE ID: CVE-2024-53080 State: PUBLISHED Published: 2024-11-19T17:45:10.820Z Last Updated: 2025-05-04T09:52:26.360Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 ("drm/panthor: Fix race when converting group handle to group object") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock. References: - https://git.kernel.org/stable/c/3342f066a8e1020a6f7d1fbd6b23bfdeda4
ation is protected by the @pool->lock. References: - https://git.kernel.org/stable/c/3342f066a8e1020a6f7d1fbd6b23bfdeda473eb5 - https://git.kernel.org/stable/c/444fa5b100e5c90550d6bccfe4476efb0391b3ca - https://project-zero.issues.chromium.org/issues/377500597
CVE ID: CVE-2024-53081 State: PUBLISHED Published: 2024-11-19T17:45:11.594Z Last Updated: 2025-11-03T22:29:03.802Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/5e1523076acf95b4ea68d19b6f27e6891267cc24 - https://git.kernel.org/stable/c/a244b82d0ae6
https://git.kernel.org/stable/c/5e1523076acf95b4ea68d19b6f27e6891267cc24 - https://git.kernel.org/stable/c/a244b82d0ae60326901f2b50c15e3118298b7ecd - https://git.kernel.org/stable/c/97ed0c0332d5525653668b31acf62ff1e6b50784 - https://git.kernel.org/stable/c/438d3085ba5b8b5bfa5290faa594e577f6ac9aa7
CVE ID: CVE-2024-53082 State: PUBLISHED Published: 2024-11-19T17:45:12.233Z Last Updated: 2025-11-03T22:29:05.254Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/f3401e3c8d339ddb6ccb2e3d11ad634b7846a806 - https://git.kernel.org/stable/c/af0aa8aecbe8985079232902894cc4cb62795691 - https://git.kernel.org/stable/c/6a18a783b1fa590ad1ed785907263e4b86adcfe2 - ht
af0aa8aecbe8985079232902894cc4cb62795691 - https://git.kernel.org/stable/c/6a18a783b1fa590ad1ed785907263e4b86adcfe2 - https://git.kernel.org/stable/c/3f7d9c1964fcd16d02a8a9d4fd6f6cb60c4cc530
CVE ID: CVE-2024-53083 State: PUBLISHED Published: 2024-11-19T17:45:12.884Z Last Updated: 2025-10-01T20:17:14.617Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/35925e2b7b404cad3db857434d3312b892b55432 - https://git.kernel.org/stable/c/74d8cee747b37cd9f5ca631f678e66e7f40f2b5f - https://git.kernel.org/
7434d3312b892b55432 - https://git.kernel.org/stable/c/74d8cee747b37cd9f5ca631f678e66e7f40f2b5f - https://git.kernel.org/stable/c/029778a4fd2c90c2e76a902b797c2348a722f1b8
CVE ID: CVE-2024-53084 State: PUBLISHED Published: 2024-11-19T17:45:13.530Z Last Updated: 2025-10-01T20:17:14.486Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler "finished" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that th
scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/cb86db12b290ed07d05df00d99fa150bb123e80e - https://git.kernel.org/stable/c/b04ce1e718bd55302b5
//git.kernel.org/stable/c/cb86db12b290ed07d05df00d99fa150bb123e80e - https://git.kernel.org/stable/c/b04ce1e718bd55302b52d05d6873e233cb3ec7a1
CVE ID: CVE-2024-53085 State: PUBLISHED Published: 2024-11-19T17:45:14.209Z Last Updated: 2025-05-04T13:00:17.431Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it wil
both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved. References: - https://git.kernel.org/stable/c/cfaf83501a0cbb104499c5b0892ee5ebde4e967f - https://git.kernel.org/stable/c/bc203fe416abdd1c29da594565a7c3c4e979488e - https://git.kernel.org/stable/c/9265fed6db601ee2ec47577815387458ef4f047a
CVE ID: CVE-2024-53086 State: PUBLISHED Published: 2024-11-19T17:45:14.846Z Last Updated: 2025-10-01T20:17:14.366Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095) Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/96397b1e25dda8389dea63ec914038a170bf953d - https://git.kernel.org/stable/c/64a2b6ed4bfd890a0e91955dd8ef8422a3944ed9
CVE ID: CVE-2024-53087 State: PUBLISHED Published: 2024-11-19T17:45:15.510Z Last Updated: 2025-10-01T20:17:14.232Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f) Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/2f92b77a8ce043fbda2664d9be4b66bdc57f67b7 - https://git.kernel
ulnrichment: References: - https://git.kernel.org/stable/c/2f92b77a8ce043fbda2664d9be4b66bdc57f67b7 - https://git.kernel.org/stable/c/af797b831d8975cb4610f396dcb7f03f4b9908e7
CVE ID: CVE-2024-53088 State: PUBLISHED Published: 2024-11-19T17:45:16.169Z Last Updated: 2025-11-03T22:29:06.753Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() with
_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: "Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, please set promiscuous on manually for VF XX". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate
VF XX". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/262dc6ea5f1eb18c4d08ad83d51222d0dd0dd42a - https://git.kernel.org/stable/c/7ad3fb3bfd43feb4e15c81dffd23ac4e55742791 - https://git.kernel.org/stable/c/bf5f837d9fd27d32fb76df0a108babcaf4446ff1 - https://git.kernel.org/stable/c/6e046f4937474bc1b9fa980c1ad8f3253fc638f6 -
c/bf5f837d9fd27d32fb76df0a108babcaf4446ff1 - https://git.kernel.org/stable/c/6e046f4937474bc1b9fa980c1ad8f3253fc638f6 - https://git.kernel.org/stable/c/f30490e9695ef7da3d0899c6a0293cc7cd373567
CVE ID: CVE-2024-53089 State: PUBLISHED Published: 2024-11-21T18:17:06.640Z Last Updated: 2025-10-01T20:17:13.999Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f ("KVM: LAPIC: Mark hrtimer to expire in hard interrupt context") and commit 9090825fa9974 ("KVM: arm/arm64: Let the timer expire in hardirq context on RT"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PRE
n the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a "scheduling while atomic" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-C