CVE-2024-50256 in Linux
Zusammenfassung
von VulDB • 30.06.2026
Based on the stack trace provided, here is an analysis of the issue.
### **Summary** This crash occurs in the Linux kernel's Netfilter subsystem when processing a packet through `nft_reject_inet`. The specific failure point is: ```c net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
```
This indicates that the **`nft_reject_inet` expression evaluation** triggered a bug, likely due to invalid packet data, missing headers, or an internal state inconsistency in how IPv6 packets are handled through bridge netfilter.
---
### **Detailed Stack Trace Analysis**
1. **Entry Point**: - The crash originates from a user-space `write()` syscall (`tun_chr_write_iter`), which sends data into a TUN/TAP device. - This triggers network stack processing: `netif_receive_skb_internal` → `br_handle_frame`.
2. **Bridge Netfilter Path**: - The packet is being processed by the bridge netfilter subsystem (`br_nf_pre_routing_ipv6`). - It enters an IPv6-specific hook in the bridge path, indicating this involves **IPv6 traffic over a Linux bridge**.
3. **Netfilter Core Processing**: - `nft_do_chain_inet` → `nft_do_chain`: The packet is being evaluated against nftables rulesets. - `expr_call_ops_eval`: An expression in the rule set is being executed. In this case, it's likely a `reject` action with the `inet` family (which handles both IPv4 and IPv6).
4. **Crash Location**: - **File**: `net/netfilter/nft_reject_inet.c` - **Line**: ~48 - This is inside the evaluation function for the reject expression in the inet family. The crash likely happens when trying to construct or send a rejection packet (e.g., ICMPv6 unreachable) back to the sender, but something goes wrong—possibly due to: - Missing IPv6 headers. - Invalid socket buffer (`skb`) state. - A bug in how `nft_reject_inet` handles certain edge cases with bridge netfilter and IPv6.
---
### **Likely Causes**
1. **Kernel Bug in `nft_reject_inet`**: - There may be a recent regression or unhandled edge case in the kernel version you are running, specifically when rejecting IPv6 packets via nftables on a bridge interface. - Common issues include: - Dereferencing NULL pointers if headers are malformed. - Incorrect handling of `skb` data offsets.
2. **Malformed Packet**: - The packet sent through the TUN device might have invalid IPv6 headers or lengths, causing the kernel to crash when trying to generate a rejection response.
3. **Bridge + Netfilter Interaction Bug**: - Combining Linux bridges with netfilter (especially `nftables`) and IPv6 can expose complex edge cases in header parsing and packet modification logic.
---
### **Recommended Actions**
1. **Check Kernel Version**: ```bash uname -r ``` If you are on a recent kernel (< 6.x), check if there is a known bug related to `nft_reject_inet` and IPv6 bridge traffic. Look for patches in the Linux netdev mailing list or stable kernels.
2. **Update Kernel**: - Upgrade to the latest stable kernel (e.g., 6.1, 6.6, or newer) where this bug may have been fixed.
3. **Workaround**: - If possible, avoid using `nftables` reject rules on bridge interfaces for IPv6 traffic temporarily. - Use iptables/nftables with explicit IPv4/IPv6 chains instead of the generic `inet` family if feasible. - Disable netfilter on the bridge interface (`br_netfilter`) if not strictly needed: ```bash echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables ```
4. **Report the Bug**: - If you can reproduce this with a minimal test case, report it to: - [Linux Kernel Mailing List (LKML)](https://lore.kernel.org/lkml/)
- [Netdev Mailing List](https://lore.kernel.org/netdev/)
- Include the full stack trace and kernel version.
5. **Debugging**: - Enable `CONFIG_KASAN` to
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.