CPE, viết tắt của Liệt kê nền tảng phổ biến, là một lược đồ đặt tên chuẩn hóa cho phần cứng, phần mềm và hệ điều hành. CPE cung cấp lược đồ đặt tên có cấu trúc để xác định và phân loại duy nhất các hệ thống công nghệ thông tin, nền tảng và gói phần mềm dựa trên các thuộc tính nhất định như nhà cung cấp, tên sản phẩm, phiên bản, cập nhật, phiên bản và ngôn ngữ.
CWE, hay Liệt kê điểm yếu phổ biến, là danh sách và phân loại toàn diện các điểm yếu và lỗ hổng phần mềm. Nó phục vụ như ngôn ngữ chung để mô tả các điểm yếu bảo mật phần mềm trong kiến trúc, thiết kế, mã hoặc triển khai có thể dẫn đến lỗ hổng.
CAPEC, viết tắt của Liệt kê và phân loại mẫu tấn công phổ biến, là tài nguyên toàn diện, có sẵn công khai ghi lại các mẫu tấn công phổ biến được đối thủ sử dụng trong các cuộc tấn công mạng. Cơ sở kiến thức này nhằm mục đích hiểu và diễn đạt các lỗ hổng phổ biến và các phương pháp kẻ tấn công sử dụng để khai thác chúng.
Dịch vụ và giá cả
Trợ giúp và thông tin
Tìm kiếm: ID CVE, ID CWE, ID CAPEC, nhà cung cấp hoặc từ khóa trong CVE
btrfs: do not assert we found block group item when creating free space tree
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not assert we found block group item when creating free space tree
Currently, when building a free space tree at populate_free_space_tree(),
if we are not using the block group tree feature, we always expect to find
block group items (either extent items or a block group item with key type
BTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree with
btrfs_search_slot_for_read(), so we assert that we found an item. However
this expectation is wrong since we can have a new block group created in
the current transaction which is still empty and for which we still have
not added the block group's item to the extent tree, in which case we do
not have any items in the extent tree associated to the block group.
The insertion of a new block group's block group item in the extent tree
happens at btrfs_create_pending_block_groups() when it calls the helper
insert_block_group_item(). This typically is done when a transaction
handle is released, committed or when running delayed refs (either as
part of a transaction commit or when serving tickets for space reservation
if we are low on free space).
So remove the assertion at populate_free_space_tree() even when the block
group tree feature is not enabled and update the comment to mention this
case.
Syzbot reported this with the following stack trace:
BTRFS info (device loop3 state M): rebuilding free space tree
assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115
------------[ cut here ]------------
kernel BUG at fs/btrfs/free-space-tree.c:1115!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115
Code: ff ff e8 d3 (...)
RSP: 0018:ffffc9000430f780 EFLAGS: 00010246
RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000
RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94
R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001
R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000
FS: 00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0
Call Trace:
btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364
btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062
btrfs_remount_rw fs/btrfs/super.c:1334 [inline]
btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559
reconfigure_super+0x227/0x890 fs/super.c:1076
do_remount fs/namespace.c:3279 [inline]
path_mount+0xd1a/0xfe0 fs/namespace.c:4027
do_mount fs/namespace.c:4048 [inline]
__do_sys_mount fs/namespace.c:4236 [inline]
__se_sys_mount+0x313/0x410 fs/namespace.c:4213
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f424e39066a
Code: d8 64 89 02 (...)
RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a
RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000
RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020
R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380
R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0
Modules linked in:
---[ end trace 0000000000000000 ]---
Thông tin CVE
EPSS
EPSS là mô hình tính điểm dự đoán khả năng một lỗ hổng bị khai thác.
Điểm EPSS
Mô hình EPSS tạo ra điểm xác suất từ 0 đến 1 (0 đến 100%). Điểm càng cao, xác suất một lỗ hổng bị khai thác càng lớn.
Ngày
EPSS V0
EPSS V1
EPSS V2 (> 2022-02-04)
EPSS V3 (> 2025-03-07)
EPSS V4 (> 2025-03-17)
2025-10-30
–
–
–
–
0.02%
2025-11-05
–
–
–
–
0.02%
2025-11-18
–
–
–
–
0.02%
2025-11-19
–
–
–
–
0.04%
2025-11-21
–
–
–
–
0.04%
2025-12-01
–
–
–
–
0.05%
2025-12-06
–
–
–
–
0.05%
2025-12-07
–
–
–
–
0.05%
2025-12-08
–
–
–
–
0.05%
2025-12-24
–
–
–
–
0.04%
2026-01-06
–
–
–
–
0.04%
2026-01-22
–
–
–
–
0.04%
2026-01-23
–
–
–
–
0.04%
2026-03-01
–
–
–
–
0.05%
2026-03-08
–
–
–
–
0.05%
2026-03-22
–
–
–
–
0.05%
2026-03-29
–
–
–
–
0.04%
2026-04-12
–
–
–
–
0.06%
2026-04-26
–
–
–
–
0.06%
2026-05-17
–
–
–
–
0.06%
2026-05-31
–
–
–
–
0.06%
2026-06-07
–
–
–
–
0.06%
2026-06-14
–
–
–
–
0.06%
Phân vị EPSS
Phân vị được dùng để xếp hạng CVE theo điểm EPSS. Ví dụ, một CVE ở phân vị thứ 95 theo điểm EPSS có nhiều khả năng bị khai thác hơn 95% CVE khác. Do đó, phân vị được dùng để so sánh điểm EPSS của một CVE với các CVE khác.