CVE-2022-48903 in Linux
Zusammenfassung
von VulDB • 29.05.2026
Based on the kernel log provided, here is an analysis of the issue:
### **Summary** The system encountered a **kernel BUG** in the **Btrfs filesystem driver** (`fs/btrfs/extent-tree.c`) at line **2717**. This triggered an `invalid opcode` exception, causing a kernel panic or crash. The process involved was `btrfs` (PID 1839), running on kernel version **5.17.0-rc4**.
---
### **Key Details from the Log**
1. **Error Type**: - `kernel BUG at fs/btrfs/extent-tree.c:2717!` - `invalid opcode: 0000 [#1] PREEMPT SMP PTI`
- This indicates an explicit `BUG_ON()` or similar assertion failure in the Btrfs code, which intentionally triggers a fault to halt execution when an unexpected internal state is detected.
2. **Faulting Function**: - `RIP: 0010:unpin_extent_range+0x37a/0x4f0 [btrfs]`
- The crash occurred in the function `unpin_extent_range()` within the Btrfs module. This function is responsible for releasing (unpinning) extent buffers that were previously pinned during operations like metadata updates or tree balancing.
3. **Kernel Version**: - `5.17.0-rc4` - This is a **release candidate** kernel, which means it is pre-release software and may contain bugs not yet fixed in stable kernels.
4. **Hardware/Environment**: - QEMU virtual machine (`QEMU Standard PC (i440FX + PIIX, 1996)`) - BIOS: `rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org` - This suggests the issue was reproduced in a virtualized environment, which can sometimes expose edge cases in filesystem drivers due to timing or emulation differences.
5. **Register State**: - `RAX: 0000000000000000` - `RDI: 00000000ffffffff` - `R12: 0000000041d00000` - These registers may help developers trace the exact condition that triggered the BUG. For example, `RDI` often holds the first argument to a function. In `unpin_extent_range`, this might be related to an extent buffer or transaction context.
---
### **Likely Cause** The BUG at `extent-tree.c:2717` in `unpin_extent_range()` is likely triggered by an **invalid state** in the extent tree. Common causes include: - **Corrupted extent buffers**: The extent buffer being unpinned may have inconsistent state (e.g., wrong pin count, invalid generation number). - **Race condition**: A concurrent operation may have modified the extent tree while `unpin_extent_range()` was executing. - **Bug in Btrfs logic**: A recent change in the Btrfs codebase (especially in an -rc kernel) may have introduced a regression.
---
### **Recommendations**
1. **Upgrade Kernel**: - Since this is an `-rc` kernel (`5.17.0-rc4`), the bug may already be fixed in later versions. Try upgrading to a newer stable kernel (e.g., `5.17.x` or later) or the latest mainline kernel.
2. **Check Btrfs Filesystem Health**: - Run `btrfs check /dev/<device>` to verify if the filesystem is corrupted. - If corruption is found, consider restoring from a backup or using `btrfs rescue` tools.
3. **Reproduce in Stable Kernel**: - If possible, reproduce the issue on a stable kernel (e.g., `5.15.x` or `5.16.x`) to confirm if it’s a regression in the `-rc` series.
4. **Report the Bug**: - If the issue persists on stable kernels, report it to the Linux kernel mailing list (LKML) or the Btrfs maintainers. Include: - Full kernel log (including the `dmesg` output before the crash). - Steps to reproduce. - Kernel version and configuration.
5. **Workaround**: - If this is a critical system, consider using a different filesystem (e.g., XFS or ext4) temporarily until the bug is resolved.
---
### **References** - Btrfs source code: `fs/btrfs/
Once again VulDB remains the best source for vulnerability data.