[LTS 9.6] CVE-2026-31402, CVE-2026-23066, CVE-2026-23097, CVE-2026-23171

[pvts-mat]

[LTS 9.6]

CVE-2026-31402	VULN-180165
CVE-2026-23066	VULN-175573
CVE-2026-23097	VULN-175621
CVE-2026-23171	VULN-176288

Commits

CVE-2026-31402

nfsd: fix heap overflow in NFSv4.0 LOCK replay cache

jira VULN-180165
cve CVE-2026-31402
commit-author Jeff Layton <jlayton@kernel.org>
commit 5133b61aaf437e5f25b1b396b14242a6bb0508e2
upstream-diff Used `post_err_offset' instead of `op_status_offset +
  XDR_UNIT' in the `read_bytes_from_xdr_buf()' call, as the LTS 9.6
  version is missing ef3675b45bcb6c17cabbbde620c6cea52ffb21ac ("NFSD:
  Encode COMPOUND operation status on page boundaries")

CVE-2026-23066

rxrpc: Fix recvmsg() unconditional requeue

jira VULN-175573
cve CVE-2026-23066
commit-author David Howells <dhowells@redhat.com>
commit 2c28769a51deb6022d7fbd499987e237a01dd63a
upstream-diff Used linux-6.12.y backport
  cf969bddd6e69c5777fa89dc88402204e72f312a as the basis, which, unlike
  the upstream, produces no conflicts in net/rxrpc/recvmsg.c and only
  trivial conflicts in include/trace/events/rxrpc.h. The contentious
  commit is the non-backported a2ea9a9072607c2fd6442bd1ffb4dbdbf882aed7
  ("Use irq-disabling spinlocks between app and I/O thread"), which
  changes spin_lock()/spin_unlock() pairs to
  spin_lock_irq()/spin_unlock_irq(). Spin locks are used in the CVE fix
  which makes the upstream version incompatible. Linux 6.12 doesn't have
  this commit backported either which makes it better suited for LTS
  9.6. Conflicts left in include/trace/events/rxrpc.h are just a matter
  of putting the newly defined trace points in a correct place on the
  alphabetically-ordered list.

Commit a2ea9a9 was considered for the backport as prerequisite, but it's quite exetensive (14 files modified), requires considerable additional work (conflicts in 4 files) and introduces CVE-2025-38525 which would have to be bugfixed too.

CVE-2026-23097

migrate: correct lock ordering for hugetlb file folios

jira VULN-175621
cve CVE-2026-23097
commit-author Matthew Wilcox (Oracle) <willy@infradead.org>
commit b7880cb166ab62c2409046b2347261abf701530e
upstream-diff Changes in the `remove_migration_ptes()' function call:
  1. Compared `rc' with `MIGRATEPAGE_SUCCESS' as it was originally,
     instead of checking if it's zero - the success code simplification
     was done in the non-backported commit
     fb49a4425cfa163faccd91f913773d3401d3a7d4 ("treewide: remove
     MIGRATEPAGE_SUCCESS").
  2. Used `false' instead of `0' in the third argument in case `ttu' is
     zero. The LTS 9.6 version of `remove_migration_ptes()' accepts
     booleans as the last argument - this was changed in the
     non-backported commit b1f202060afeb7fcb98473929d26fd3d2093b067 ("mm:
     remap unused subpages to shared zeropage when splitting isolated
     thp"). For the same reason used `true' instead of `RMP_LOCKED' in
     case it's non-zero. Inside the LTS 9.6 version of
     `remove_migration_ptes()' it narrows down to the
     `rmap_walk_locked(dst, &rwc)' call, just like in the upstream.

The solution is basically the same as centos9 7db3700, except for formatting.

CVE-2026-23171

bonding: fix use-after-free due to enslave fail after slave array update

jira VULN-176288
cve CVE-2026-23171
commit-author Nikolay Aleksandrov <razor@blackwall.org>
commit e9acda52fd2ee0cdca332f996da7a95c5fd25294
upstream-diff Accounted for the missing commit
  e0caeb24f538c3c9c94f471882ceeb43d9dc2739 ("net: bonding: update the
  slave array for broadcast mode"): moved the conditional
  `bond_update_slave_arr()' call to the same place regardless of the
  condition differing from the upstream.

The LTS 9.6 version is missing e0caeb2 which changes the condition for the moved code fragment, causing conflicts in applying the upstream fix. That commit is a fix for ce7a381 net: bonding: add broadcast_neighbor option for 802.3ad, which was not backported to LTS 9.6 and should not be backported as part of CVE-2026-23171 fixing effort as it introduces new feature. The fix was therefore adapted manually.

Since the mechanism of the bug, as well as its fix, was not entirely clear, and no other backports of this fix to a Linux version with the e0caeb2 commit missing were found, the reproduction of the bug was attempted to make sure the proposed fix actually solves the problem.

Bug reproduction

From the fixing commit e9acda5 message:

It is very easy to reproduce the problem with a simple xdp_pass prog:
ip l add bond1 type bond mode balance-xor
ip l set bond1 up
ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass
ip l add dumdum type dummy

Then run in parallel:
while :; do ip l set dumdum master bond1 1>/dev/null 2>&1; done;
mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp "dp=1-1023, flags=syn"

Config

To reproduce the issue tha KASAN option was enabled in ciqlts9_6. However, merely setting

CONFIG_KASAN=y

in the default config kernel-x86_64-rhel.config resulted in a kernel which was crashing on boot. Instead the kernel-x86_64-debug-rhel.config configuration was used which happened to have KASAN enabled and was nevertheless booting fine for some reason.

kasan-crashing.log

The "xdp_pass prog"

The xdp_pass prog mentioned in the commit message was assumed to be a minimal XDP eBPF program whose behavior is just to return XDP_PASS:

#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

SEC("xdp_pass")
int xdp_prog(struct xdp_md *ctx)
{
    return XDP_PASS;
}

char _license[] SEC("license") = "GPL";

Compilation:

clang -I/usr/src/kernels/5.14.0-611.55.1.el9_7.x86_64+debug/tools/bpf/resolve_btfids/libbpf/include -O2 -g -target bpf -c xdp_pass.c -o xdp_pass.o

The bpf/bpf_helpers.h header was only available after installing kernel-debug-devel package

sudo dnf --color=never install kernel-debug-devel.x86_64 -y

Bug reproduction on ciqlts9_6

Commands from the commit message were used to reproduce the bug, namely

ip l add bond1 type bond mode balance-xor
ip l set bond1 up
ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass
ip l add dumdum type dummy
while :; do ip l set dumdum master bond1 1>/dev/null 2>&1; done;

in one console and

mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp "dp=1-1023, flags=syn"

in another.

The reported KASAN message was not obtained on any run. Insted the kernel was spontaneously rebooting right after the mausezahn command invocation.

ciqlts9_6–reproduction-console-1.log
ciqlts9_6–reproduction-console-2.log

Patch test

Similarly to the bug reproduction on ciqlts9_6 the patched version was compiled under the kernel-x86_64-debug-rhel.config configuration file. Repeating the same steps resulted in no reboots, crashes or hangs.

ciqlts9_6-patched–reproduction-console-1.log
ciqlts9_6-patched–reproduction-console-2.log

kABI check: passed

[0/1] kabi_check_kernel	Check ABI of kernel [ciqlts9_6-CVE-batch-32]	_kabi_check_kernel__x86_64--test--ciqlts9_6-CVE-batch-32
+ dist_git_version=el-9.6
+ local_version=ciqlts9_6-CVE-batch-32
+ arch=x86_64
+ user=pvts
+ buildmachine=x86_64--build--ciqlts9_6
+ virsh_timeout=600
+ ssh_daemon_wait=20
+ src_dir=/mnt/code/kernel-dist-git-el-9.6
+ build_dir=/mnt/build_files/kernel-src-tree-ciqlts9_6-CVE-batch-32
+ sudo chmod +x /data/src/ctrliq-github-haskell/kernel-dist-git-el-9.6/SOURCES/check-kabi
+ ninja-back/virssh.xsh --max 8 --shutdown-on-success --shutdown-on-failure --timeout 600 --ssh-daemon-wait 20 pvts x86_64--build--ciqlts9_6 ''\''/mnt/code/kernel-dist-git-el-9.6/SOURCES/check-kabi'\'' -k '\''/mnt/code/kernel-dist-git-el-9.6/SOURCES/Module.kabi_x86_64'\'' -s '\''/mnt/build_files/kernel-src-tree-ciqlts9_6-CVE-batch-32/Module.symvers'\'''
kABI check passed
+ touch state/kernels/ciqlts9_6-CVE-batch-32/x86_64/kabi_checked

Boot test: passed

boot-test.log

Kselftests: passed relative

Reference

kselftests–ciqlts9_6–run1.log

Patch

kselftests–ciqlts9_6-CVE-batch-32–run1.log

Comparison

The tests results for the reference and the patch are the same.

$ ktests.xsh diff -d kselftests*.log

Column    File
--------  --------------------------------------------
Status0   kselftests--ciqlts9_6--run1.log
Status1   kselftests--ciqlts9_6-CVE-batch-32--run1.log

tests-comparison.txt