Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-37816 State: PUBLISHED Published: 2025-05-08T06:26:12.063Z Last Updated: 2025-05-26T05:21:29.215Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mei: vsc: Fix fortify-panic caused by invalid counted_by() use gcc 15 honors the __counted_by(len) attribute on vsc_tp_packet.buf[] and the vsc-tp.c code is using this in a wrong way. len does not contain the available size in the buffer, it contains the actual packet length *without* the crc. So as soon as vsc_tp_xfer() tries to add the crc to buf[] the fortify-panic handler gets triggered: [ 80.842193] memcpy: detected buffer overflow: 4 byte write of buffer size 0 [
the fortify-panic handler gets triggered: [ 80.842193] memcpy: detected buffer overflow: 4 byte write of buffer size 0 [ 80.842243] WARNING: CPU: 4 PID: 272 at lib/string_helpers.c:1032 __fortify_report+0x45/0x50 ... [ 80.843175] __fortify_panic+0x9/0xb [ 80.843186] vsc_tp_xfer.cold+0x67/0x67 [mei_vsc_hw] [ 80.843210] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90 [ 80.843229] ? lockdep_hardirqs_on+0x7c/0x110 [ 80.843250] mei_vsc_hw_start+0x98/0x120 [mei_vsc] [ 80.843270] mei_reset+0x11d/0x420 [mei] The easiest fix would be to just drop the counted-by but with the exception of the ack buffer in vsc_tp_xfer_helper() which only contains enough room for the packet-header, all other uses
xception of the ack buffer in vsc_tp_xfer_helper() which only contains enough room for the packet-header, all other uses of vsc_tp_packet always use a buffer of VSC_TP_MAX_XFER_SIZE bytes for the packet. Instead of just dropping the counted-by, split the vsc_tp_packet struct definition into a header and a full-packet definition and use a fixed size buf[] in the packet definition, this way fortify-source buffer overrun checking still works when enabled. References: - https://git.kernel.org/stable/c/3e243378f27cc7d11682a3ad720228b0723affa5 - https://git.kernel.org/stable/c/ac04663c67f244810b3492e9ecd9f7cdbefeca2d - https://git.kernel.org/stable/c/00f1cc14da0f06d2897b8c528df7c7dcf1b8da50
CVE ID: CVE-2025-37817 State: PUBLISHED Published: 2025-05-08T06:26:12.683Z Last Updated: 2025-11-03T19:55:49.346Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mcb: fix a double free bug in chameleon_parse_gdd() In chameleon_parse_gdd(), if mcb_device_register() fails, 'mdev' would be released in mcb_device_register() via put_device(). Thus, goto 'err' label and free 'mdev' again causes a double free. Just return if mcb_device_register() fails. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/d70184958b0ea8c0fd52e2b456654b503e769fc8 - https://git.kernel.org/stable/c/4ffe8c9fb561
https://git.kernel.org/stable/c/d70184958b0ea8c0fd52e2b456654b503e769fc8 - https://git.kernel.org/stable/c/4ffe8c9fb561e4427dd1a3056cd5b3685b74f78d - https://git.kernel.org/stable/c/59f993cd36b6e28a394ba3d977e8ffe5c9884e3b - https://git.kernel.org/stable/c/c5b8a549ef1fcc6066b037a3962c79d60465ba0b - https://git.kernel.org/stable/c/96838eb1836fd372e42be5db84f0b333b65146a6 - https://git.kernel.org/stable/c/df1a5d5c6134224f9298e5189230f9d29ae50cac - https://git.kernel.org/stable/c/bcc7d58ee5173e34306026bd01e1fbf75e169d37 - https://git.kernel.org/stable/c/7c7f1bfdb2249f854a736d9b79778c7e5a29a150
CVE ID: CVE-2025-37818 State: PUBLISHED Published: 2025-05-08T06:26:13.322Z Last Updated: 2025-11-03T19:55:50.705Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: LoongArch: Return NULL from huge_pte_offset() for invalid PMD LoongArch's huge_pte_offset() currently returns a pointer to a PMD slot even if the underlying entry points to invalid_pte_table (indicating no mapping). Callers like smaps_hugetlb_range() fetch this invalid entry value (the address of invalid_pte_table) via this pointer. The generic is_swap_pte() check then incorrectly identifies this address as a swap entry on LoongArch, because it satisfies the "!pte_pres
p_pte() check then incorrectly identifies this address as a swap entry on LoongArch, because it satisfies the "!pte_present() && !pte_none()" conditions. This misinterpretation, combined with a coincidental match by is_migration_entry() on the address bits, leads to kernel crashes in pfn_swap_entry_to_page(). Fix this at the architecture level by modifying huge_pte_offset() to check the PMD entry's content using pmd_none() before returning. If the entry is invalid (i.e., it points to invalid_pte_table), return NULL instead of the pointer to the slot. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/34256805720993e37adf6127371a1265aea8376a - htt
s: - CVE Program Container: References: - https://git.kernel.org/stable/c/34256805720993e37adf6127371a1265aea8376a - https://git.kernel.org/stable/c/2ca9380b12711afe95b3589bd82b59623b3c96b3 - https://git.kernel.org/stable/c/51424fd171cee6a33f01f7c66b8eb23ac42289d4 - https://git.kernel.org/stable/c/b49f085cd671addbda4802d6b9382513f7dd0f30 - https://git.kernel.org/stable/c/bd51834d1cf65a2c801295d230c220aeebf87a73
CVE ID: CVE-2025-37819 State: PUBLISHED Published: 2025-05-08T06:26:13.975Z Last Updated: 2025-11-03T19:55:52.082Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode() With ACPI in place, gicv2m_get_fwnode() is registered with the pci subsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtime during a PCI host bridge probe. But, the call back is wrongly marked as __init, causing it to be freed, while being registered with the PCI subsystem and could trigger: Unable to handle kernel paging request at virtual address ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (
d could trigger: Unable to handle kernel paging request at virtual address ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (P) pci_set_bus_msi_domain+0x74/0x88 pci_register_host_bridge+0x194/0x548 This is easily reproducible on a Juno board with ACPI boot. Retain the function for later use. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/0c241dedc43a036599757cd08f356253fa3e5014 - https://git.kernel.org/stable/c/b63de43af8d215b0499eac28b2caa4439183efc1 - https://git.kernel.org/stable/c/f95659affee301464f0d058d528d96b35b452da8 - https://git.kernel.org/stable/c/dc0d654eb4179b06d3206e4396d072108b9ba082 - https://git.kernel.org/stable/c/2f2803e4b5e4df2
tps://git.kernel.org/stable/c/dc0d654eb4179b06d3206e4396d072108b9ba082 - https://git.kernel.org/stable/c/2f2803e4b5e4df2b08d378deaab78b1681ef9b30 - https://git.kernel.org/stable/c/3939d6f29d34cdb60e3f68b76e39e00a964a1d51 - https://git.kernel.org/stable/c/47bee0081b483b077c7560bc5358ad101f89c8ef - https://git.kernel.org/stable/c/3318dc299b072a0511d6dfd8367f3304fb6d9827
CVE ID: CVE-2025-37820 State: PUBLISHED Published: 2025-05-08T06:26:14.602Z Last Updated: 2025-11-03T19:55:53.465Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xen-netfront: handle NULL returned by xdp_convert_buff_to_frame() The function xdp_convert_buff_to_frame() may return NULL if it fails to correctly convert the XDP buffer into an XDP frame due to memory constraints, internal errors, or invalid data. Failing to check for NULL may lead to a NULL pointer dereference if the result is used later in processing, potentially causing crashes, data corruption, or undefined behavior. On XDP redirect failure, the associated page m
ing, potentially causing crashes, data corruption, or undefined behavior. On XDP redirect failure, the associated page must be released explicitly if it was previously retained via get_page(). Failing to do so may result in a memory leak, as the pages reference count is not decremented. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/5b83d30c63f9964acb1bc63eb8e670b9e0d2c240 - https://git.kernel.org/stable/c/cefd8a2e2de46209ce66e6d30c237eb59b6c5bfa - https://git.kernel.org/stable/c/d6a9c4e6f9b3ec3ad98468c950ad214af8a2efb9 - https://git.kernel.org/stable/c/eefccd889df3b49d92e7349d94c4aa7e1ba19f6c - https://git.kernel.org/stable/c/cc3628dcd851ddd
tps://git.kernel.org/stable/c/eefccd889df3b49d92e7349d94c4aa7e1ba19f6c - https://git.kernel.org/stable/c/cc3628dcd851ddd8d418bf0c897024b4621ddc92
CVE ID: CVE-2025-37821 State: PUBLISHED Published: 2025-05-08T06:26:15.535Z Last Updated: 2025-05-26T05:21:36.453Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sched/eevdf: Fix se->slice being set to U64_MAX and resulting crash There is a code path in dequeue_entities() that can set the slice of a sched_entity to U64_MAX, which sometimes results in a crash. The offending case is when dequeue_entities() is called to dequeue a delayed group entity, and then the entity's parent's dequeue is delayed. In that case: 1. In the if (entity_is_task(se)) else block at the beginning of dequeue_entities(), slice is set to cfs_rq_min_slice
e: 1. In the if (entity_is_task(se)) else block at the beginning of dequeue_entities(), slice is set to cfs_rq_min_slice(group_cfs_rq(se)). If the entity was delayed, then it has no queued tasks, so cfs_rq_min_slice() returns U64_MAX. 2. The first for_each_sched_entity() loop dequeues the entity. 3. If the entity was its parent's only child, then the next iteration tries to dequeue the parent. 4. If the parent's dequeue needs to be delayed, then it breaks from the first for_each_sched_entity() loop _without updating slice_. 5. The second for_each_sched_entity() loop sets the parent's ->slice to the saved slice, which is still U64_MAX. This throws off subsequent calculations with potentially
e parent's ->slice to the saved slice, which is still U64_MAX. This throws off subsequent calculations with potentially catastrophic results. A manifestation we saw in production was: 6. In update_entity_lag(), se->slice is used to calculate limit, which ends up as a huge negative number. 7. limit is used in se->vlag = clamp(vlag, -limit, limit). Because limit is negative, vlag > limit, so se->vlag is set to the same huge negative number. 8. In place_entity(), se->vlag is scaled, which overflows and results in another huge (positive or negative) number. 9. The adjusted lag is subtracted from se->vruntime, which increases or decreases se->vruntime by a huge number. 10. pick_eevdf() calls enti
is subtracted from se->vruntime, which increases or decreases se->vruntime by a huge number. 10. pick_eevdf() calls entity_eligible()/vruntime_eligible(), which incorrectly returns false because the vruntime is so far from the other vruntimes on the queue, causing the (vruntime - cfs_rq->min_vruntime) * load calulation to overflow. 11. Nothing appears to be eligible, so pick_eevdf() returns NULL. 12. pick_next_entity() tries to dereference the return value of pick_eevdf() and crashes. Dumping the cfs_rq states from the core dumps with drgn showed tell-tale huge vruntime ranges and bogus vlag values, and I also traced se->slice being set to U64_MAX on live systems (which was usually "benign"
ges and bogus vlag values, and I also traced se->slice being set to U64_MAX on live systems (which was usually "benign" since the rest of the runqueue needed to be in a particular state to crash). Fix it in dequeue_entities() by always setting slice from the first non-empty cfs_rq. References: - https://git.kernel.org/stable/c/86b37810fa1e40b93171da023070b99ccbb4ea04 - https://git.kernel.org/stable/c/50a665496881262519f115f1bfe5822f30580eb0 - https://git.kernel.org/stable/c/bbce3de72be56e4b5f68924b7da9630cc89aa1a8
CVE ID: CVE-2025-37822 State: PUBLISHED Published: 2025-05-08T06:26:16.209Z Last Updated: 2025-05-26T05:21:37.724Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: riscv: uprobes: Add missing fence.i after building the XOL buffer The XOL (execute out-of-line) buffer is used to single-step the replaced instruction(s) for uprobes. The RISC-V port was missing a proper fence.i (i$ flushing) after constructing the XOL buffer, which can result in incorrect execution of stale/broken instructions. This was found running the BPF selftests "test_progs: uprobe_autoattach, attach_probe" on the Spacemit K1/X60, where the uprobes tests randoml
the BPF selftests "test_progs: uprobe_autoattach, attach_probe" on the Spacemit K1/X60, where the uprobes tests randomly blew up. References: - https://git.kernel.org/stable/c/bcf6d3158c5902d92b6d62335af4422b7bf7c4e2 - https://git.kernel.org/stable/c/1dbb95a36499374c51b47ee8ae258a8862c20978 - https://git.kernel.org/stable/c/7d1d19a11cfbfd8bae1d89cc010b2cc397cd0c48
CVE ID: CVE-2025-37823 State: PUBLISHED Published: 2025-05-08T06:26:16.839Z Last Updated: 2025-11-03T19:55:56.301Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too Similarly to the previous patch, we need to safe guard hfsc_dequeue() too. But for this one, we don't have a reliable reproducer. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/68f256305ceb426d545a0dc31f83c2ab1d211a1e - https://git.kernel.org/stable/c/2f46d14919c39528c6e540ebc43f90055993eedc - https://git.kernel.org/stable/c/da7936518996d290e2fcfcaf6cd7e15bfd878
table/c/2f46d14919c39528c6e540ebc43f90055993eedc - https://git.kernel.org/stable/c/da7936518996d290e2fcfcaf6cd7e15bfd87804a - https://git.kernel.org/stable/c/11bccb054c1462fb069219f8e98e97a5a730758e - https://git.kernel.org/stable/c/76c4c22c2437d3d3880efc0f62eca06ef078d290 - https://git.kernel.org/stable/c/c6f035044104c6ff656f4565cd22938dc892528c - https://git.kernel.org/stable/c/c6936266f8bf98a53f28ef9a820e6a501e946d09 - https://git.kernel.org/stable/c/6ccbda44e2cc3d26fd22af54c650d6d5d801addf
CVE ID: CVE-2025-37824 State: PUBLISHED Published: 2025-05-08T06:26:17.476Z Last Updated: 2025-11-03T19:55:59.094Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tipc: fix NULL pointer dereference in tipc_mon_reinit_self() syzbot reported: tipc: Node number set to 1055423674 Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3
.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events tipc_net_finalize_work RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:
fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/proces
c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> ... RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719 ... RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010 RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007 R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS
fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010 FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 There is a racing condition between workqueue created when enabling bearer and another thread created when disabling bearer right after that as follow: enabling_bearer | disabling_bearer --------------- | ---------------- tipc_disc_timeout() | { | bearer_disable() ... | { schedule_work(&tn->work); | tipc_mon_delet
------- | ---------------- tipc_disc_timeout() | { | bearer_disable() ... | { schedule_work(&tn->work); | tipc_mon_delete() ... | { } | ... | write_lock_bh(&mon->lock); | mon->self = NULL; | write_unlock_bh(&mon->lock); | ... | } tipc_net_finalize_work() | } { | ... | tipc_net_finalize() | { | ... | tipc_mon_reinit_self() | { | ... | write_lock_bh(&mon->lock); | mon->self->addr = tipc_own_addr(net); | write_unlock_bh(&mon->lock); | ... ---truncated--- Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a3df56010403b2cd26388096ebccf959d23c4dcc - https://git.kernel.org/stable/c/e6613b6d41f4010c4d484cbc7bfca690d8d522a2 - https://git.kernel.org/stable
cf959d23c4dcc - https://git.kernel.org/stable/c/e6613b6d41f4010c4d484cbc7bfca690d8d522a2 - https://git.kernel.org/stable/c/5fd464fd24de93d0eca377554bf0ff2548f76f30 - https://git.kernel.org/stable/c/e79e8e05aa46f90d21023f0ffe6f136ed6a20932 - https://git.kernel.org/stable/c/dd6cb0a8575b00fbd503e96903184125176f4fa3 - https://git.kernel.org/stable/c/0ceef62a328ce1288598c9242576292671f21e96 - https://git.kernel.org/stable/c/4d5e1e2d3e9d70beff7beab44fd6ce91405a405e - https://git.kernel.org/stable/c/d63527e109e811ef11abb1c2985048fdb528b4cb
CVE ID: CVE-2025-37825 State: PUBLISHED Published: 2025-05-08T06:26:18.094Z Last Updated: 2025-05-26T05:21:41.660Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nvmet: fix out-of-bounds access in nvmet_enable_port When trying to enable a port that has no transport configured yet, nvmet_enable_port() uses NVMF_TRTYPE_MAX (255) to query the transports array, causing an out-of-bounds access: [ 106.058694] BUG: KASAN: global-out-of-bounds in nvmet_enable_port+0x42/0x1da [ 106.058719] Read of size 8 at addr ffffffff89dafa58 by task ln/632 [...] [ 106.076026] nvmet: transport type 255 not supported Since commit 200adac75888, NVMF_TR
ff89dafa58 by task ln/632 [...] [ 106.076026] nvmet: transport type 255 not supported Since commit 200adac75888, NVMF_TRTYPE_MAX is the default state as configured by nvmet_ports_make(). Avoid this by checking for NVMF_TRTYPE_MAX before proceeding. References: - https://git.kernel.org/stable/c/83c00860a37b3fcba8026cb344101f1b8af547cf - https://git.kernel.org/stable/c/3d7aa0c7b4e96cd460826d932e44710cdeb3378b
CVE ID: CVE-2025-37826 State: PUBLISHED Published: 2025-05-08T06:26:18.694Z Last Updated: 2025-05-26T05:21:42.938Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Add NULL check in ufshcd_mcq_compl_pending_transfer() Add a NULL check for the returned hwq pointer by ufshcd_mcq_req_to_hwq(). This is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fix ufshcd_abort_one racing issue"). References: - https://git.kernel.org/stable/c/eeab6618037be84e438e9d6ed5d9a53502faf81f - https://git.kernel.org/stable/c/700128d67d57bb1de4251e563ab85202def36c50 - https://git.kernel.org/stable/c/08a966a917fe3d92150fa3cc15
ernel.org/stable/c/700128d67d57bb1de4251e563ab85202def36c50 - https://git.kernel.org/stable/c/08a966a917fe3d92150fa3cc15793ad5e57051eb
CVE ID: CVE-2025-37827 State: PUBLISHED Published: 2025-05-08T06:26:19.320Z Last Updated: 2025-05-26T05:21:44.197Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: return EIO on RAID1 block group write pointer mismatch There was a bug report about a NULL pointer dereference in __btrfs_add_free_space_zoned() that ultimately happens because a conversion from the default metadata profile DUP to a RAID1 profile on two disks. The stack trace has the following signature: BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profile BUG: kernel NULL pointer dereference, address: 0000000000000058
write pointer offset mismatch of zones in raid1 profile BUG: kernel NULL pointer dereference, address: 0000000000000058 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:__btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 RSP: 0018:ffffa236b6f3f6d0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff96c8132f3400 RCX: 0000000000000001 RDX: 0000000010000000 RSI: 0000000000000000 RDI: ffff96c8132f3410 RBP: 0000000010000000 R08: 0000000000000003 R09: 0000000000000000 R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000 R13: ffff96c758f65a40 R14: 0000000000000001 R15: 000011aac0000000 FS: 00007fd
11: 00000000ffffffff R12: 0000000000000000 R13: ffff96c758f65a40 R14: 0000000000000001 R15: 000011aac0000000 FS: 00007fdab1cb2900(0000) GS:ffff96e60ca00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000058 CR3: 00000001a05ae000 CR4: 0000000000350ef0 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15c/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __btrfs_add_free_space_zoned.isra.0+0x61/0x1a0 btrfs_add_free_space_async_trimmed+0x34/0x40 btrfs_add_new_free_space+0x107/0x120 btrfs_make_block_group+0x104/0x2b0 btrfs_create_chunk+0x977/0xf20 btrfs_chunk_alloc+0x174/0x510 ? srso_return_thunk+0x5/0x5f btrfs_in
ock_group+0x104/0x2b0 btrfs_create_chunk+0x977/0xf20 btrfs_chunk_alloc+0x174/0x510 ? srso_return_thunk+0x5/0x5f btrfs_inc_block_group_ro+0x1b1/0x230 btrfs_relocate_block_group+0x9e/0x410 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x8ac/0x12b0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? __kmalloc_cache_noprof+0x14c/0x3e0 btrfs_ioctl+0x2686/0x2a80 ? srso_return_thunk+0x5/0x5f ? ioctl_has_perm.constprop.0.isra.0+0xd2/0x120 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x82/0x160 ? srso_return_thunk+0x5/0x5f ? __memcg_slab_free_hook+0x11a/0x170 ? srso_return_thunk+0x5/0x5f ? kmem_cache_free+0x3f0/0x450 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_
0x5/0x5f ? kmem_cache_free+0x3f0/0x450 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? sysfs_emit+0xaf/0xc0 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? seq_read_iter+0x207/0x460 ? srso_return_thunk+0x5/0x5f ? vfs_read+0x29c/0x370 ? srso_return_thunk+0x5/0x5f ? srso_return_thunk+0x5/0x5f ? syscall_exit_to_user_mode+0x10/0x210 ? srso_return_thunk+0x5/0x5f ? do_syscall_64+0x8e/0x160 ? srso_return_thunk+0x5/0x5f ? exc_page_fault+0x7e/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdab1e0ca6d RSP: 002b:00007ffeb2b60c80 EFLAGS: 00000246 ORIG_RAX: 0000000000000010