Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
after_hwframe+0x76/0x7e RIP: 0033:0x7fdab1e0ca6d RSP: 002b:00007ffeb2b60c80 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdab1e0ca6d RDX: 00007ffeb2b60d80 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 00007ffeb2b60cd0 R08: 0000000000000000 R09: 0000000000000013 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffeb2b6343b R14: 00007ffeb2b60d80 R15: 0000000000000001 </TASK> CR2: 0000000000000058 ---[ end trace 0000000000000000 ]--- The 1st line is the most interesting here: BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profile When a RAID1 block-group is created and a write poi
sdc): zoned: write pointer offset mismatch of zones in raid1 profile When a RAID1 block-group is created and a write pointer mismatch between the disks in the RAID set is detected, btrfs sets the alloc_offset to the length of the block group marking it as full. Afterwards the code expects that a balance operation will evacuate the data in this block-group and repair the problems. But before this is possible, the new space of this block-group will be accounted in the free space cache. But in __btrfs_ ---truncated--- References: - https://git.kernel.org/stable/c/9a447f748f6c7287dad68fa91913cd382fa0fcc8 - https://git.kernel.org/stable/c/f4717a02cc422cf4bb2dbb280b154a1ae65c5f84 - https://git.ker
287dad68fa91913cd382fa0fcc8 - https://git.kernel.org/stable/c/f4717a02cc422cf4bb2dbb280b154a1ae65c5f84 - https://git.kernel.org/stable/c/b0c26f47992672661340dd6ea931240213016609
CVE ID: CVE-2025-37828 State: PUBLISHED Published: 2025-05-08T06:26:20.135Z Last Updated: 2025-05-26T05:21:45.612Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: mcq: Add NULL check in ufshcd_mcq_abort() A race can occur between the MCQ completion path and the abort handler: once a request completes, __blk_mq_free_request() sets rq->mq_hctx to NULL, meaning the subsequent ufshcd_mcq_req_to_hwq() call in ufshcd_mcq_abort() can return a NULL pointer. If this NULL pointer is dereferenced, the kernel will crash. Add a NULL check for the returned hwq pointer. If hwq is NULL, log an error and return FAILED, preventing a po
ll crash. Add a NULL check for the returned hwq pointer. If hwq is NULL, log an error and return FAILED, preventing a potential NULL-pointer dereference. As suggested by Bart, the ufshcd_cmd_inflight() check is removed. This is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fix ufshcd_abort_one racing issue"). This is found by our static analysis tool KNighter. References: - https://git.kernel.org/stable/c/d6979fabe812a168d5053e5a41d5a2e9b8afd7bf - https://git.kernel.org/stable/c/7d002f591486f5ef4bc02eb02025a53f931f0eb5 - https://git.kernel.org/stable/c/47eec518aef3814f64a5da43df81bdd74d8c0041 - https://git.kernel.org/stable/c/4c324085062919d4e21c69e5e78456dcec0052fe
CVE ID: CVE-2025-37829 State: PUBLISHED Published: 2025-05-08T06:26:21.061Z Last Updated: 2025-11-03T19:56:02.302Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate() cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. scpi_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ad4796f2da495b2cbbd0fccccbcbf63f2aeee613 - https://git.kernel.org/stable/c/fdf035d9c5436536ffcfea0ac6adeb5dda3c3a23 -
/c/ad4796f2da495b2cbbd0fccccbcbf63f2aeee613 - https://git.kernel.org/stable/c/fdf035d9c5436536ffcfea0ac6adeb5dda3c3a23 - https://git.kernel.org/stable/c/8fbaa76690f67a7cbad315f89d607b46e3e06ede - https://git.kernel.org/stable/c/da8ee91e532486055ecf88478d38c2f3dc234182 - https://git.kernel.org/stable/c/19e0eaa62e8831f2bc0285fef3bf8faaa7f3e09b - https://git.kernel.org/stable/c/28fbd7b13b4d3074b16db913aedc9d8d37ab41e7 - https://git.kernel.org/stable/c/124bddf123311cd1f18bffd63a5d974468d59c67 - https://git.kernel.org/stable/c/73b24dc731731edf762f9454552cb3a5b7224949
CVE ID: CVE-2025-37830 State: PUBLISHED Published: 2025-05-08T06:26:21.736Z Last Updated: 2025-11-03T19:56:03.977Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate() cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. scmi_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference. Add NULL check after cpufreq_cpu_get_raw() to prevent this issue. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/4e3d1c1925d8e752992cd893d03d974e6807ac16 - https://
CVE Program Container: References: - https://git.kernel.org/stable/c/4e3d1c1925d8e752992cd893d03d974e6807ac16 - https://git.kernel.org/stable/c/f9c5423855e3687262d881aeee5cfb3bc8577bff - https://git.kernel.org/stable/c/ea834c90aa7cc80a1b456f7a91432734d5087d16 - https://git.kernel.org/stable/c/7ccfadfb2562337b4f0462a86a9746a6eea89718 - https://git.kernel.org/stable/c/cfaca93b8fe317b7faa9af732e0ba8c9081fa018 - https://git.kernel.org/stable/c/484d3f15cc6cbaa52541d6259778e715b2c83c54
CVE ID: CVE-2025-37831 State: PUBLISHED Published: 2025-05-08T06:26:22.328Z Last Updated: 2025-05-26T05:21:50.541Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cpufreq: apple-soc: Fix null-ptr-deref in apple_soc_cpufreq_get_rate() cpufreq_cpu_get_raw() can return NULL when the target CPU is not present in the policy->cpus mask. apple_soc_cpufreq_get_rate() does not check for this case, which results in a NULL pointer dereference. References: - https://git.kernel.org/stable/c/1053dcf8a504d4933bb3f73df22bc363298d194b - https://git.kernel.org/stable/c/fbdba5f37413dbc09d82ad7235e5b7a2fb8e0f75 - https://git.kernel.org/stable/c/01e
98d194b - https://git.kernel.org/stable/c/fbdba5f37413dbc09d82ad7235e5b7a2fb8e0f75 - https://git.kernel.org/stable/c/01e86ea22610d98ae6141e428019a6916e79f725 - https://git.kernel.org/stable/c/9992649f6786921873a9b89dafa5e04d8c5fef2b
CVE ID: CVE-2025-37832 State: REJECTED Published: 2025-05-08T06:26:22.965Z Last Updated: 2025-06-04T07:43:57.082Z Description: No description available.
CVE ID: CVE-2025-37833 State: PUBLISHED Published: 2025-05-08T06:26:23.821Z Last Updated: 2025-05-26T05:21:54.880Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry reads Fix niu_try_msix() to not cause a fatal trap on sparc systems. Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev to work around a bug in the hardware or firmware. For each vector entry in the msix table, niu chips will cause a fatal trap if any registers in that entry are read before that entries' ENTRY_DATA register is written to. Testing indicates writes to other registers are not
try are read before that entries' ENTRY_DATA register is written to. Testing indicates writes to other registers are not sufficient to prevent the fatal trap, however the value does not appear to matter. This only needs to happen once after power up, so simply rebooting into a kernel lacking this fix will NOT cause the trap. NON-RESUMABLE ERROR: Reporting on cpu 64 NON-RESUMABLE ERROR: TPC [0x00000000005f6900] <msix_prepare_msi_desc+0x90/0xa0> NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffff NON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000] NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f9
0000000000000000:0000000000000000:0000000000000000] NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff] NON-RESUMABLE ERROR: type [precise nonresumable] NON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv > NON-RESUMABLE ERROR: raddr [0xffffffffffffffff] NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c] NON-RESUMABLE ERROR: size [0x8] NON-RESUMABLE ERROR: asi [0x00] CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63 Workqueue: events work_for_cpu_fn TSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not tainted TPC: <msix_prepare_msi_desc+0x90/0xa0> g0: 00000000000002e9 g1: 000000000000000c g2: 000
05f6904 Y: 00000000 Not tainted TPC: <msix_prepare_msi_desc+0x90/0xa0> g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100 g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000 o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620 o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128 RPC: <__pci_enable_msix_range+0x3cc/0x460> l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020 l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734 i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 00000000000
l6: 0000000020000000 l7: ffff800047a0b734 i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000d i4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0 I7: <niu_try_msix.constprop.0+0xc0/0x130 [niu]> Call Trace: [<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu] [<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu] [<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu] [<00000000005ef3e4>] local_pci_probe+0x28/0x74 [<0000000000469240>] work_for_cpu_fn+0x8/0x1c [<000000000046b008>] process_scheduled_works+0x144/0x210 [<000000000046b518>] worker_thread+0x13c/0x1c0 [<00000000004710e0>] kthread+0xb8/0xc8 [<0000000000406
_works+0x144/0x210 [<000000000046b518>] worker_thread+0x13c/0x1c0 [<00000000004710e0>] kthread+0xb8/0xc8 [<00000000004060c8>] ret_from_fork+0x1c/0x2c [<0000000000000000>] 0x0 Kernel panic - not syncing: Non-resumable error. References: - https://git.kernel.org/stable/c/c187aaa9e79b4b6d86ac7ba941e579ad33df5538 - https://git.kernel.org/stable/c/64903e4849a71cf7f7c7e5d45225ccefc1280929 - https://git.kernel.org/stable/c/fbb429ddff5c8e479edcc7dde5a542c9295944e6
CVE ID: CVE-2025-37834 State: PUBLISHED Published: 2025-05-08T06:26:24.463Z Last Updated: 2025-05-26T05:21:56.229Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: don't try to reclaim hwpoison folio Syzkaller reports a bug as follows: Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000 Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapback
000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff) raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9 raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 page dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)) ------------[ cut here ]------------ kernel BUG at mm/swap_state.c:184! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3 Hardware name: linux,dummy-virt (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : add_to_
84e #3 Hardware name: linux,dummy-virt (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : add_to_swap+0xbc/0x158 lr : add_to_swap+0xbc/0x158 sp : ffff800087f37340 x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780 x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0 x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4 x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000 x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 000
b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000 x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001 x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000 Call trace: add_to_swap+0xbc/0x158 shrink_folio_list+0x12ac/0x2648 shrink_inactive_list+0x318/0x948 shrink_lruvec+0x450/0x720 shrink_node_memcgs+0x280/0x4a8 shrink_node+0x128/0x978 balance_pgdat+0x4f0/0xb20 kswapd+0x228/0x438 kthread+0x214/0x230 ret_from_fork+0x10/0x20 I can reproduce this issue with the following steps: 1) When a dirty swapcache page is isolated by reclaim process and the page isn't locked, inject memory failure
g steps: 1) When a dirty swapcache page is isolated by reclaim process and the page isn't locked, inject memory failure for the page. me_swapcache_dirty() clears uptodate flag and tries to delete from lru, but fails. Reclaim process will put the hwpoisoned page back to lru. 2) The process that maps the hwpoisoned page exits, the page is deleted the page will never be freed and will be in the lru forever. 3) If we trigger a reclaim again and tries to reclaim the page, add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is cleared. To fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the hwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap i
ed page in shrink_folio_list(). Besides, the hwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap it in shrink_folio_list(), otherwise the folio will fail to be unmaped by hwpoison_user_mappings() since the folio isn't in lru list. References: - https://git.kernel.org/stable/c/1c9798bf8145a92abf45aa9d38a6406d9eb8bdf0 - https://git.kernel.org/stable/c/912e9f0300c3564b72a8808db406e313193a37ad - https://git.kernel.org/stable/c/1b0449544c6482179ac84530b61fc192a6527bfd
CVE ID: CVE-2025-37835 State: REJECTED Published: 2025-05-09T06:40:02.866Z Last Updated: 2025-05-10T14:01:10.747Z Description: No description available.
CVE ID: CVE-2025-37836 State: PUBLISHED Published: 2025-05-09T06:41:47.341Z Last Updated: 2025-11-03T19:56:06.788Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PCI: Fix reference leak in pci_register_host_bridge() If device_register() fails, call put_device() to give up the reference to avoid a memory leak, per the comment at device_register(). Found by code review. [bhelgaas: squash Dan Carpenter's double free fix from https://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain] Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/f4db1b2c9ae3d013733c302ee70cac9
al Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/f4db1b2c9ae3d013733c302ee70cac943b7070c0 - https://git.kernel.org/stable/c/3297497ad2246eb9243849bfbbc57a0dea97d76e - https://git.kernel.org/stable/c/b783478e0c53ffb4f04f25fb4e21ef7f482b05df - https://git.kernel.org/stable/c/bd2a352a0d72575f1842d28c14c10089f0cfe1ae - https://git.kernel.org/stable/c/9707d0c932f41006a2701afc926b232b50e356b4 - https://git.kernel.org/stable/c/bbba4c50a2d2a1d3f3bf31cc4b8280cb492bf2c7 - https://git.kernel.org/stable/c/f9208aec86226524ec1cb68a09ac70e974ea6536 - https://git.kernel.org/stable/c/804443c1f27883926de94c849d91f5b7d7d696e9
CVE ID: CVE-2025-37837 State: PUBLISHED Published: 2025-05-09T06:41:48.164Z Last Updated: 2025-05-26T05:21:58.878Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu/tegra241-cmdqv: Fix warnings due to dmam_free_coherent() Two WARNINGs are observed when SMMU driver rolls back upon failure: arm-smmu-v3.9.auto: Failed to register iommu arm-smmu-v3.9.auto: probe with driver arm-smmu-v3 failed with error -22 ------------[ cut here ]------------ WARNING: CPU: 5 PID: 1 at kernel/dma/mapping.c:74 dmam_free_coherent+0xc0/0xd8 Call trace: dmam_free_coherent+0xc0/0xd8 (P) tegra241_vintf_free_lvcmdq+0x74/0x188 tegra241_cmdqv_remove_vint
+0xc0/0xd8 Call trace: dmam_free_coherent+0xc0/0xd8 (P) tegra241_vintf_free_lvcmdq+0x74/0x188 tegra241_cmdqv_remove_vintf+0x60/0x148 tegra241_cmdqv_remove+0x48/0xc8 arm_smmu_impl_remove+0x28/0x60 devm_action_release+0x1c/0x40 ------------[ cut here ]------------ 128 pages are still in use! WARNING: CPU: 16 PID: 1 at mm/page_alloc.c:6902 free_contig_range+0x18c/0x1c8 Call trace: free_contig_range+0x18c/0x1c8 (P) cma_release+0x154/0x2f0 dma_free_contiguous+0x38/0xa0 dma_direct_free+0x10c/0x248 dma_free_attrs+0x100/0x290 dmam_free_coherent+0x78/0xd8 tegra241_vintf_free_lvcmdq+0x74/0x160 tegra241_cmdqv_remove+0x98/0x198 arm_smmu_impl_remove+0x28/0x60 devm_action_release+0x1c/0x40 This is because
0x74/0x160 tegra241_cmdqv_remove+0x98/0x198 arm_smmu_impl_remove+0x28/0x60 devm_action_release+0x1c/0x40 This is because the LVCMDQ queue memory are managed by devres, while that dmam_free_coherent() is called in the context of devm_action_release(). Jason pointed out that "arm_smmu_impl_probe() has mis-ordered the devres callbacks if ops->device_remove() is going to be manually freeing things that probe allocated": https://lore.kernel.org/linux-iommu/20250407174408.GB1722458@nvidia.com/ In fact, tegra241_cmdqv_init_structures() only allocates memory resources which means any failure that it generates would be similar to -ENOMEM, so there is no point in having that "falling back to standard
ny failure that it generates would be similar to -ENOMEM, so there is no point in having that "falling back to standard SMMU" routine, as the standard SMMU would likely fail to allocate memory too. Remove the unwind part in tegra241_cmdqv_init_structures(), and return a proper error code to ask SMMU driver to call tegra241_cmdqv_remove() via impl_ops->device_remove(). Then, drop tegra241_vintf_free_lvcmdq() since devres will take care of that. References: - https://git.kernel.org/stable/c/e5dd974d6e00704553308ef1a88659f8dcfb39d4 - https://git.kernel.org/stable/c/5584dbf393df509159813645a487b1ef76557722 - https://git.kernel.org/stable/c/e38ed6908080047d8fa1763d1da86b584f9eb55b - https://git.k
f509159813645a487b1ef76557722 - https://git.kernel.org/stable/c/e38ed6908080047d8fa1763d1da86b584f9eb55b - https://git.kernel.org/stable/c/767e22001dfce64cc03b7def1562338591ab6031
CVE ID: CVE-2025-37838 State: PUBLISHED Published: 2025-04-18T14:20:55.389Z Last Updated: 2025-11-03T19:56:09.541Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HSI: ssi_protocol: Fix use after free vulnerability in ssi_protocol Driver Due to Race Condition In the ssi_protocol_probe() function, &ssi->work is bound with ssip_xmit_work(), In ssip_pn_setup(), the ssip_pn_xmit() function within the ssip_pn_ops structure is capable of starting the work. If we remove the module which will call ssi_protocol_remove() to make a cleanup, it will free ssi through kfree(ssi), while the work mentioned above will be used. The sequence of op
to make a cleanup, it will free ssi through kfree(ssi), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ssip_xmit_work ssi_protocol_remove | kfree(ssi); | | struct hsi_client *cl = ssi->cl; | // use ssi Fix it by ensuring that the work is canceled before proceeding with the cleanup in ssi_protocol_remove(). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/d03abc1c2b21324550fa71e12d53e7d3498e0af6 - https://git.kernel.org/stable/c/4a8c29beb8a02b5a0a9d77d608aa14b6f88a6b86 - https://git.kernel.org/stable/c/72972552d0d0bfeb2dec5daf343a19018db36ffa
le/c/4a8c29beb8a02b5a0a9d77d608aa14b6f88a6b86 - https://git.kernel.org/stable/c/72972552d0d0bfeb2dec5daf343a19018db36ffa - https://git.kernel.org/stable/c/d58493832e284f066e559b8da5ab20c15a2801d3 - https://git.kernel.org/stable/c/58eb29dba712ab0f13af59ca2fe545f5ce360e78 - https://git.kernel.org/stable/c/ae5a6a0b425e8f76a9f0677e50796e494e89b088 - https://git.kernel.org/stable/c/834e602d0cc7c743bfce734fad4a46cefc0f9ab1 - https://git.kernel.org/stable/c/4b4194c9a7a8f92db39e8e86c85f4fb12ebbec4f - https://git.kernel.org/stable/c/e3f88665a78045fe35c7669d2926b8d97b892c11
CVE ID: CVE-2025-37839 State: PUBLISHED Published: 2025-05-09T06:41:49.105Z Last Updated: 2025-11-03T19:56:12.328Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: jbd2: remove wrong sb->s_sequence check Journal emptiness is not determined by sb->s_sequence == 0 but rather by sb->s_start == 0 (which is set a few lines above). Furthermore 0 is a valid transaction ID so the check can spuriously trigger. Remove the invalid WARN_ON. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/cf30432f5b3064ff85d85639c2f0106f89c566f6 - https://git.kernel.org/stable/c/b479839525fe7906966cdc4b5b2afbca
org/stable/c/cf30432f5b3064ff85d85639c2f0106f89c566f6 - https://git.kernel.org/stable/c/b479839525fe7906966cdc4b5b2afbca048558a1 - https://git.kernel.org/stable/c/ad926f735b4d4f10768fec7d080cadeb6d075cac - https://git.kernel.org/stable/c/3b4643ffaf72d7a5a357e9bf68b1775f8cfe7e77 - https://git.kernel.org/stable/c/c88f7328bb0fff66520fc9164f02b1d06e083c1b - https://git.kernel.org/stable/c/9eaec071f111cd2124ce9a5b93536d3f6837d457 - https://git.kernel.org/stable/c/c98eb9ffb1d9c98237b5e1668eee17654e129fb0 - https://git.kernel.org/stable/c/b0cca357f85beb6144ab60c62dcc98508cc044bf - https://git.kernel.org/stable/c/e6eff39dd0fe4190c6146069cc16d160e71d1148
CVE ID: CVE-2025-37840 State: PUBLISHED Published: 2025-05-09T06:41:50.015Z Last Updated: 2025-11-03T19:56:15.093Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: brcmnand: fix PM resume warning Fixed warning on PM resume as shown below caused due to uninitialized struct nand_operation that checks chip select field : WARN_ON(op->cs >= nanddev_ntargets(&chip->base) [ 14.588522] ------------[ cut here ]------------ [ 14.588529] WARNING: CPU: 0 PID: 1392 at drivers/mtd/nand/raw/internals.h:139 nand_reset_op+0x1e0/0x1f8 [ 14.588553] Modules linked in: bdc udc_core [ 14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tain
eset_op+0x1e0/0x1f8 [ 14.588553] Modules linked in: bdc udc_core [ 14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tainted: G W 6.14.0-rc4-g5394eea10651 #16 [ 14.588590] Tainted: [W]=WARN [ 14.588593] Hardware name: Broadcom STB (Flattened Device Tree) [ 14.588598] Call trace: [ 14.588604] dump_backtrace from show_stack+0x18/0x1c [ 14.588622] r7:00000009 r6:0000008b r5:60000153 r4:c0fa558c [ 14.588625] show_stack from dump_stack_lvl+0x70/0x7c [ 14.588639] dump_stack_lvl from dump_stack+0x18/0x1c [ 14.588653] r5:c08d40b0 r4:c1003cb0 [ 14.588656] dump_stack from __warn+0x84/0xe4 [ 14.588668] __warn from warn_slowpath_fmt+0x18c/0x194 [ 14.588678] r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000
0xe4 [ 14.588668] __warn from warn_slowpath_fmt+0x18c/0x194 [ 14.588678] r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000 [ 14.588681] warn_slowpath_fmt from nand_reset_op+0x1e0/0x1f8 [ 14.588695] r8:70c40dff r7:89705f41 r6:36b4a597 r5:c26c9444 r4:c26b0048 [ 14.588697] nand_reset_op from brcmnand_resume+0x13c/0x150 [ 14.588714] r9:00000000 r8:00000000 r7:c24f8010 r6:c228a3f8 r5:c26c94bc r4:c26b0040 [ 14.588717] brcmnand_resume from platform_pm_resume+0x34/0x54 [ 14.588735] r5:00000010 r4:c0840a50 [ 14.588738] platform_pm_resume from dpm_run_callback+0x5c/0x14c [ 14.588757] dpm_run_callback from device_resume+0xc0/0x324 [ 14.588776] r9:c24f8054 r8:c24f80a0 r7:00000000 r6:00000000 r5:00000010 r