---
title: "Linux Kernel Vulnerabilities CVE-2026-43284 and CVE-2026-43500 (Dirty Frag)"
description: "## Overview This article provides additional technical details regarding the Linux kernel vulnerabilities: `CVE-2026-43284` `CVE-2026-43500` These vulnerabilities are collectively referred to as **Dirty Frag** and affect specific Linux kernel packet handling paths associated with: - XFRM/IPsec - ESP (Encapsulating Security…"
url: "https://www.relianoid.com/resources/knowledge-base/troubleshooting/linux-kernel-vulnerabilities-cve-2026-43284-and-cve-2026-43500-dirty-frag/"
updated: "2026-05-12"
category: Troubleshooting
---

# Linux Kernel Vulnerabilities CVE-2026-43284 and CVE-2026-43500 (Dirty Frag)

## Overview

This article provides additional technical details regarding the Linux kernel vulnerabilities:

`CVE-2026-43284`
 `CVE-2026-43500`

These vulnerabilities are collectively referred to as **Dirty Frag** and affect specific Linux kernel packet handling paths associated with:

- XFRM/IPsec
- ESP (Encapsulating Security Payload)
- Shared socket buffer fragments (skb frags)
- UDP packet splice handling

Official references:

[NVD – CVE-2026-43284](https://nvd.nist.gov/vuln/detail/CVE-2026-43284)
 [NVD – CVE-2026-43500](https://nvd.nist.gov/vuln/detail/CVE-2026-43500)

## Technical Background

### CVE-2026-43284

According to the Linux kernel maintainers, the vulnerability originates from improper handling of:

- Shared skb fragments
- UDP splice page handling
- ESP in-place decryption operations

The issue occurs because:

 `MSG_SPLICE_PAGES` may attach externally owned pages directly into packet buffers UDP paths failed to mark those fragments as shared using: `SKBFL_SHARED_FRAG`

As a consequence:

- ESP processing incorrectly assumes packet data is privately owned
- ESP decryption may occur directly over shared memory
- Memory corruption or unintended data modification may become possible

The upstream kernel fix introduces:

- Proper fragment ownership tracking
- Additional copy-on-write protections
- Safer fallback behavior using: `skb_cow_data()`

### CVE-2026-43500

At the time of writing:

- CVE-2026-43500 remains in Reserved status
- Public technical details are still limited

However, it is associated with the same Dirty Frag vulnerability family and kernel networking subsystem.

## RELIANOID Exposure Analysis

### Standard RELIANOID Deployments

RELIANOID itself does not use:

- Custom UDP splice page processing
- Raw ESP packet manipulation
- Direct XFRM kernel interactions

Therefore, standard RELIANOID deployments are not exposed under normal operating conditions.

### VPN configured RELIANOID Deployments

RELIANOID deployments where the VPN functionality (**Network > VPN**) or custom VPN setups are enabled may use Linux IPsec/XFRM functionality depending on the VPN configuration.

This means:

- IPsec-related kernel modules can be loaded when VPN/IPsec features are enabled
- ESP/XFRM modules may become active
- The affected kernel paths could theoretically become reachable

### Potentially Loaded Modules

When VPN/IPsec functionality is configured, the following modules may appear:

```
esp4
esp6
xfrm_user
xfrm_algo
xfrm4_mode_transport
xfrm4_mode_tunnel
xfrm6_mode_transport
xfrm6_mode_tunnel
```

### Risk Assessment for RELIANOID VPN Users

At present:

- No known active exploitation against RELIANOID VPN deployments has been identified
- Exploitation conditions appear highly specific
- The vulnerability requires complex packet handling conditions involving shared skb fragments

However, systems actively using IPsec VPN functionality should be considered potentially exposed until patched kernels are applied.

### How to Determine If RELIANOID VPN Is Using IPsec

Check loaded modules:

```
lsmod | egrep 'esp|xfrm'
```

### Check Active IPsec States

```
ip xfrm state
```

### Check Active IPsec Policies

```
ip xfrm policy
```

If active VPN tunnels exist, output similar to the following may appear:

```
src 10.0.0.1 dst 10.0.1.1
proto esp spi 0x00000001
```

## Mitigation Recommendations

### Systems NOT Using VPN/IPsec

If VPN functionality is not required:

**Unload Modules and clean caches**

```
modprobe -r esp4 esp6 xfrm_user xfrm_algo
sync; echo 3 > /proc/sys/vm/drop_caches
```

**Blacklist Modules**

Create:

```
/etc/modprobe.d/disable-xfrm.conf
```

Contents:

```
blacklist esp4
blacklist esp6
blacklist xfrm_user
blacklist xfrm_algo
blacklist xfrm4_mode_transport
blacklist xfrm4_mode_tunnel
blacklist xfrm6_mode_transport
blacklist xfrm6_mode_tunnel
```

### Systems USING RELIANOID VPN/IPsec

If the VPN module is actively used:

**Recommended Actions**

- Apply vendor kernel updates immediately when available
- Restrict VPN exposure to trusted peers only
- Limit unnecessary third-party software
- Monitor RELIANOID security advisories
- Monitor abnormal kernel/network behavior

Patches to fix this vulnerability will be provided in the releases EE > 8.5

## Additional Hardening Recommendations

### Restrict Untrusted Packet Sources

Use firewall rules to limit:

- Public ESP exposure
- Untrusted UDP encapsulation traffic
- External VPN peers

### Minimize Third-Party Kernel Interaction

Avoid:

- Custom packet manipulation frameworks
- Untrusted networking software
- Experimental kernel modules

## Validation After Mitigation

Confirm affected modules are not loaded:

```
lsmod | egrep 'esp|xfrm'
```

Expected result:

```
(no output)
```

## Summary

The Dirty Frag vulnerabilities `CVE-2026-43284` and `CVE-2026-43500` affect Linux kernel ESP/XFRM processing associated with IPsec networking.

**Key Clarification**

- Standard RELIANOID load balancing functionality is not affected
- However, the RELIANOID VPN/IPsec module may load the impacted kernel modules
- Systems using: **Network > VPN** or custom VPN setups should evaluate exposure and apply mitigations accordingly

RELIANOID recommends:

- Disabling unused IPsec functionality
- Applying vendor kernel updates
- Restricting exposure of VPN services
- Monitoring official kernel security advisories

### 📄 Download this document in PDF format