[LTS 8.6] nfsd: CVE-2026-31402#1223
Open
pvts-mat wants to merge 1 commit into
Open
Conversation
jira VULN-180161 cve CVE-2026-31402 commit-author Jeff Layton <jlayton@kernel.org> commit 5133b61 upstream-diff Used `post_err_offset' instead of `op_status_offset + XDR_UNIT' in the `read_bytes_from_xdr_buf()' call, as the LTS 8.6 version is missing ef3675b ("NFSD: Encode COMPOUND operation status on page boundaries") The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses. This size was calculated based on OPEN responses and does not account for LOCK denied responses, which include the conflicting lock owner as a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT). When a LOCK operation is denied due to a conflict with an existing lock that has a large owner, nfsd4_encode_operation() copies the full encoded response into the undersized replay buffer via read_bytes_from_xdr_buf() with no bounds check. This results in a slab-out-of-bounds write of up to 944 bytes past the end of the buffer, corrupting adjacent heap memory. This can be triggered remotely by an unauthenticated attacker with two cooperating NFSv4.0 clients: one sets a lock with a large owner string, then the other requests a conflicting lock to provoke the denial. We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full opaque, but that would increase the size of every stateowner, when most lockowners are not that large. Instead, fix this by checking the encoded response length against NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the response is too large, set rp_buflen to 0 to skip caching the replay payload. The status is still cached, and the client already received the correct response on the original request. Fixes: 1da177e ("Linux-2.6.12-rc2") Cc: stable@kernel.org Reported-by: Nicholas Carlini <npc@anthropic.com> Tested-by: Nicholas Carlini <npc@anthropic.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> (cherry picked from commit 5133b61) Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
pvts-mat
force-pushed
the
CVE-2026-31402_ciqlts8_6
branch
from
142428d to
0efc019
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
[LTS 8.6]
Commits
The changes are the same as in
rocky8_10for the buildable kernel 9b906d0, compare withThey are the same, in turn, as the solutions for LTS 9.2 and and LTS 9.4. Unlike in the LTS 9.2 solution the fixes for CVE-2025-40324 and CVE-2023-53241 were not included because they don't apply cleanly - too high hanging fruits to get for their worth.
kABI check: passed
Boot test: passed
boot-test.log
Kselftests: passed relative
Reference
kselftests–ciqlts8_6–run1.log
kselftests–ciqlts8_6–run2.log
Patch
kselftests–ciqlts8_6-CVE-2026-31402–run1.log
kselftests–ciqlts8_6-CVE-2026-31402–run2.log
Comparison
The tests results for the reference and the patch are the same.
tests-comparison.txt