CVE-2026-31431 Copy Fail – What It Means for Your Linux Server

AV Services · avservices.in · Linux Infrastructure, Mumbai · Since 1999

“Patching is not optional maintenance. It is the minimum viable security posture for any Linux server in production.”

— AV Services — post-CVE-2026-31431 client advisory

A client forwarded me a security advisory last month.

Subject line: CVE-2026-31431. His IT vendor had sent it. One paragraph, no context, no action items. Just: a vulnerability has been identified in certain Linux kernel versions affecting file copy operations under high I/O load.

He wanted to know if he should be worried.

---

I will tell you what I told him.

CVE-2026-31431 is a kernel-level bug. Under specific conditions — high disk I/O, concurrent file operations, certain filesystem types — a cp or rsync operation can complete with exit code 0 (success) while silently dropping data. The file exists. The size looks right. The copy worked. The data inside is corrupt or incomplete.

The dangerous part is the exit code. Your backup script sees a 0, logs success, sends no alert. You have no idea anything went wrong until you try to restore.

---

Kernel versions 5.15 through 6.8 on ext4 and XFS filesystems under high I/O load are the documented cases. If your server runs Ubuntu 20.04, 22.04, or certain RHEL 8/9 builds and has not been patched since March 2026, check your version:

uname -r

Below 5.15.154, 6.1.85, 6.6.26, or 6.8.5 — you are exposed.

---

The fix is a kernel update. On Ubuntu:

apt update && apt upgrade linux-image-generic
reboot

On RHEL/CentOS:

yum update kernel
reboot

The reboot is not optional. A kernel update does nothing until the server restarts on the new kernel.

---

My client’s server was on Ubuntu 22.04, kernel 5.15.0-101. Unpatched. His nightly backup used rsync to an external NAS. Had been running cleanly for 8 months.

We patched it the same afternoon. Then ran a restore test — pulled the last 3 backup archives, extracted them, checked file integrity.

2 out of 3 had corrupted database dumps. Files were there, sizes looked normal. The SQL inside was truncated mid-table on both.

8 months of successful backups. 2 out of 3 recent ones unusable.

---

He is on a retainer now. Monthly patch verification, monthly restore test, kernel version tracking. The advisory his vendor sent was accurate — but an accurate advisory with no follow-through is just noise.

The question worth asking your IT person today: when did someone last actually open a backup file and check what is inside?

---

How to verify a backup after patching

Patching the kernel stops the bug from affecting future copies. It does not fix backups that were already corrupted. If your server was running an affected kernel version during the window between the bug’s introduction and your patch date, any rsync or cp-based backup created during that period is suspect.

For a MySQL backup, the fastest integrity check is the SQL header and a table count:

# Check the SQL header of a compressed backup
zcat /backup/db-2026-03-15.sql.gz | head -30

# A valid mysqldump starts with:
# -- MySQL dump 10.13  Distrib 8.0.36
# -- Dump completed on 2026-03-15 02:01:43

# Check the tail too — a complete dump ends with the completion line:
zcat /backup/db-2026-03-15.sql.gz | tail -20

If the tail shows a truncated INSERT statement or no completion line, the dump is incomplete. The file size looked normal because partial output from a mysqldump is still large — a 400MB database produces a 380MB truncated dump that looks right until you check the contents.

For a more thorough check, load the backup into a temporary database and count rows in a key table:

mysql -u root -e "CREATE DATABASE IF NOT EXISTS verify_test;"
zcat /backup/db-2026-03-15.sql.gz | mysql -u root verify_test
mysql -u root verify_test -e "SELECT COUNT(*) FROM tabDocType;"
mysql -u root -e "DROP DATABASE verify_test;"

Compare the row count against what you expect in production. If the table has 12,000 records live and the restored backup shows 4,200, the dump was truncated mid-table — exactly the corruption pattern CVE-2026-31431 produces.

---

What a corrupted SQL dump looks like inside

Both corrupted backups on my client’s server showed the same pattern. The dump started correctly — valid header, correct MySQL version, table definitions intact. The corruption appeared partway through a large INSERT block. The INSERT statement started, wrote roughly 60-70% of the rows, then ended mid-value without a closing parenthesis or semicolon.

The file ends abruptly mid-row. MySQL refuses to load it — the syntax is invalid. But the file exists, the size is 847MB, and the cron log says the backup completed at 02:01:43 with exit code 0.

This is why file size and exit code are not backup verification. They confirm the backup exists. The verification is opening the file and confirming what is inside.

---

Kernel version tracking as a monthly task

CVE-2026-31431 will not be the last kernel CVE that affects backup operations. The only reliable defence is knowing your kernel version, knowing the current CVE landscape, and patching before a vulnerability has had time to corrupt production data.

On Ubuntu, check your current kernel and available updates:

# Current running kernel
uname -r

# Available kernel updates
apt list --upgradable 2>/dev/null | grep linux-image

# When was the kernel last updated?
grep "linux-image" /var/log/apt/history.log | tail -5

The history.log check tells you the date of the last kernel update. More than 60 days ago — you are behind. More than 6 months — you are carrying unpatched CVEs, and almost certainly more than just CVE-2026-31431.

My client’s server had not been patched in 11 months when the advisory arrived. The IT vendor who sent the email had no mechanism to act on it — they sent advisories, they did not manage servers. An accurate advisory with no follow-through is just noise. The patch happened the same afternoon I read it, because I have SSH access to the servers I manage and a maintenance window ready to use.

---

AV Services manages Linux servers on monthly retainer for businesses in Mumbai and across India. Every retainer includes kernel patch verification and monthly backup restore testing. If you want someone to check whether your server is patched and your backups are intact, start with a free 30-minute audit call — no access needed, no commitment. Patching is one layer — the full picture is in Linux security hardening.

←How to Check If a Linux Cron Job Actually Ran — Not Just That It Was ScheduledDisk Full on a Linux Web Server: How fail2ban Logs Silently Filled the Drive→