Skip to content

[CBR 7.9] CVE-2025-40240, CVE-2026-31402, CVE-2018-16885#1350

Open
pvts-mat wants to merge 2 commits into
ctrliq:ciqcbr7_9from
pvts-mat:CVE-batch-35_ciqcbr7_9
Open

[CBR 7.9] CVE-2025-40240, CVE-2026-31402, CVE-2018-16885#1350
pvts-mat wants to merge 2 commits into
ctrliq:ciqcbr7_9from
pvts-mat:CVE-batch-35_ciqcbr7_9

Conversation

@pvts-mat

@pvts-mat pvts-mat commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

[CBR 7.9]

CVE-2025-40240 VULN-176137
CVE-2026-31402 VULN-180160
CVE-2018-16885 VULN-184749

Commits

CVE-2025-40240

sctp: avoid NULL dereference when chunk data buffer is missing

jira VULN-176137
cve CVE-2025-40240
commit-author Alexey Simakov <bigalex934@gmail.com>
commit 441f0647f7673e0e64d4910ef61a5fb8f16bfb82
upstream-diff Same change as in upstream, except for ciqcbr7_9's
  SCTP_INC_STATS_BH macro instead of upstream's __SCTP_INC_STATS. It's
  the same macro, renamed on upstream in
  13415e46c5915e2dac089de516369005fbc045f9 ("net: snmp: kill STATS_BH
  macros")

CVE-2026-31402

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

jira VULN-180160
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 CBR 7.9
  version is missing ef3675b45bcb6c17cabbbde620c6cea52ffb21ac ("NFSD:
  Encode COMPOUND operation status on page boundaries")

CVE-2018-16885

CBR 7.9 is not affected by this bug since c3ad1c3.

Situation

On December 21, 2018 RH published a bug, described as

A flaw was found in the Linux kernel that allows the userspace to call memcpy_fromiovecend() and similar functions with a zero offset and buffer length. This can cause a read beyond the buffer boundaries flaw and, in certain cases, cause a memory access fault and a system halt by accessing invalid memory address

From the same page:

Note: this is a RHEL-only bug.

There is no upstream commit (or any other for that matter) identified as the fix, neither on RH CVE-2018-16885 page nor others (NIST, CVE.org). No more detailed explanation of the problem was found anywhere.

On August 6, 2019 an errata page RHSA-2019:2029 was published containing the fix for RHEL 7, version kernel-0:3.10.0-1062.el7 (https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2018-16885.json), with the fix identified as

kernel: out-of-bound read in memcpy_fromiovecend() (CVE-2018-16885)

This specific kernel version can be found in CBR 7.9 history at c3ad1c3. It contains only four line changes in the net/core/iovec.c file (the one containing memcpy_fromiovecend() function mentioned), aligning perfectly with the short problem description given in the bug page:

$ git log --date=iso --pretty=oneline --patch-with-stat -n 1 c3ad1c3e7302742989d83875b14d77fd232661ef -- net/core/iovec.c

c3ad1c3e7302742989d83875b14d77fd232661ef (tag: centos_kernel-3.10.0-1062.el7) Rebuild centos7 with kernel-3.10.0-1062.el7
 net/core/iovec.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/core/iovec.c b/net/core/iovec.c
index 3e23152424a66ef568ec3599bfec1ff24cb8a0e8..0a0feb0e4e20507de6322dcfa9f06bad10e06cdd 100644
--- a/net/core/iovec.c
+++ b/net/core/iovec.c
@@ -164,7 +164,7 @@ int memcpy_fromiovecend(unsigned char *kdata, const struct iovec *iov,
 			int offset, int len)
 {
 	/* Skip over the finished iovecs */
-	while (offset >= iov->iov_len) {
+	while (offset && offset >= iov->iov_len) {
 		offset -= iov->iov_len;
 		iov++;
 	}
@@ -192,7 +192,7 @@ int memcpy_fromiovecend_partial_flushcache(unsigned char *kdata,
 	int orig_len = len;
 
 	/* Skip over the finished iovecs */
-	while (offset >= iov->iov_len) {
+	while (offset && offset >= iov->iov_len) {
 		offset -= iov->iov_len;
 		iov++;
 	}
@@ -226,7 +226,7 @@ int memcpy_fromiovecend_partial_nocache(unsigned char *kdata,
 	int orig_len = len;
 
 	/* Skip over the finished iovecs */
-	while (offset >= iov->iov_len) {
+	while (offset && offset >= iov->iov_len) {
 		offset -= iov->iov_len;
 		iov++;
 	}
@@ -262,7 +262,7 @@ int csum_partial_copy_fromiovecend(unsigned char *kdata, struct iovec *iov,
 	int partial_cnt = 0, err = 0;
 
 	/* Skip over the finished iovecs */
-	while (offset >= iov->iov_len) {
+	while (offset && offset >= iov->iov_len) {
 		offset -= iov->iov_len;
 		iov++;
 	}

The "similar functions" mentioned in the bug description apparently are csum_partial_copy_fromiovecend(), memcpy_fromiovecend_partial_nocache() and memcpy_fromiovecend_partial_flushcache().

On May 26, 2026 RH published an errata page RHSA-2026:14925 for RHEL 7 ELS containing the same fix

kernel: out-of-bound read in memcpy_fromiovecend() (CVE-2018-16885)

and linking to the same bug page. The patched kernel version was kernel-0:3.10.0-1160.149.1.el7, strongly suggesting that the CVE-2018-16885 fix was already in place from the kernel-0:3.10.0-1062.el7 patched revision. The reason for RH patching this kernel again is not clear.

The bug

Consider the memcpy_fromiovecend() function from before c3ad1c3 (centos_kernel-3.10.0-1062.el7 tag):

kernel-src-tree/net/core/iovec.c

Lines 163 to 185 in 460ce23

int memcpy_fromiovecend(unsigned char *kdata, const struct iovec *iov,
int offset, int len)
{
/* Skip over the finished iovecs */
while (offset >= iov->iov_len) {
offset -= iov->iov_len;
iov++;
}
while (len > 0) {
u8 __user *base = iov->iov_base + offset;
int copy = min_t(unsigned int, len, iov->iov_len - offset);
offset = 0;
if (copy_from_user(kdata, base, copy))
return -EFAULT;
len -= copy;
kdata += copy;
iov++;
}
return 0;
}

It implements the vectorized I/O scatter/gather pattern. It copies len bytes of data scattered across the user-space iov array to the contiguous kernel buffer kdata. The offset argument allows to skip initial offset bytes of copying, so the sum offset + len must not be greater than the total number of bytes in the iov chunks. The struct iovec specifies a single chunk of data and has a simple "pointer + size" definition:

kernel-src-tree/include/uapi/linux/uio.h

Lines 16 to 20 in 460ce23

struct iovec
{
void __user *iov_base; /* BSD uses caddr_t (1003.1g requires void *) */
__kernel_size_t iov_len; /* Must be size_t (1003.1g) */
};

The size of iov array is not given explicitly (let alone bound-checked) anywhere; instead it's assumed the user knows how many bytes collectively the iov chunks contain and doesn't request with offset + len any more than that (failure to ensure that was the exact reason for the bug described in https://lists.openvz.org/pipermail/devel/2018-December/072970.html - more on that later).

Different elements of the memcpy_fromiovecend() mechanism can be graphed as follows (all labels denote variables, unless quoted):

           offset                       len
   |----------------------|-----------------------------|
                              copy
                          |---------|

                 iov[i]->base
                 |
                 ' iov[i]->iov_len
   |--------|----|------------------|--------|--------|----------------|  "iov chunks"
i= 0        1    2        .         3        4        5
                          |
                          base

   \_____________/        \_____________________________/
  "finished iovecs"               "copied data"
   \___________________________________________________________________/
                    "total data size contained by iov"

Note that, despite forming a line above, the iov chunks are not necessarily contiguous in memory - they were put in line just to better illustrate the sizes arithmetics.

The CVE-2018-16885 bug occurs in the first stage of skipping the "finished iovecs":

kernel-src-tree/net/core/iovec.c

Lines 167 to 170 in 460ce23

while (offset >= iov->iov_len) {
offset -= iov->iov_len;
iov++;
}

If the initial offset equals the total number of bytes contained in the iov chunks, then the loop above, upon ultimately reaching the end of iov and reducing offset to 0 (perhaps without any iterations if iov was empty and offset was 0 from the start), will attempt to execute an additional iteration for the iov pointer laying outside the boundary of the original iov array.

This problem is actually more general than what CVE-2018-16885 description states, namely memcpy_fromiovecend() not being able to cope with offset = N, where N is the total size of data contained in iov. The bug page describes the special case of N = 0.

The issue may be fixed by checking whether offset became 0 and breaking the loop right then. This is exactly what the change in c3ad1c3 does:

kernel-src-tree/net/core/iovec.c

Lines 167 to 170 in c3ad1c3

while (offset && offset >= iov->iov_len) {
offset -= iov->iov_len;
iov++;
}

Similar code

It was evaluated whether the additional fixing of CVE-2018-16885 in RHEL 7 ELS was associated with other instances of offset >= iov->iov_len pattern in the net/core/iovec.c file, for example in memcpy_toiovecend():

kernel-src-tree/net/core/iovec.c

Lines 81 to 100 in 460ce23

int memcpy_toiovecend(const struct iovec *iov, unsigned char *kdata,
int offset, int len)
{
int copy;
for (; len > 0; ++iov) {
/* Skip over the finished iovecs */
if (unlikely(offset >= iov->iov_len)) {
offset -= iov->iov_len;
continue;
}
copy = min_t(unsigned int, iov->iov_len - offset, len);
if (copy_to_user(iov->iov_base + offset, kdata, copy))
return -EFAULT;
offset = 0;
kdata += copy;
len -= copy;
}
return 0;
}

(Similar situation in memcpy_toiovecend_partial() and memcpy_toiovecend_partial_mcsafe().) However, unlike memcpy_fromiovecend() and similar, the memcpy_toiovecend() family guards offset >= iov->iov_len checks with len > 0 condition. Assuming that these functions are called properly, that is with offset + len <= N condition fulfilled, the problematic offset = N situation implies len = 0, which would prevent the "finished iovecs skipping" loop from falling out of iov bounds, as it happens in memcpy_fromiovecend().

Discussion of other solutions

Three other solutions (to not necessarily the same problem) surfaced on the RH's bug page. They are discussed below to shed more light on the issue.

  1. UFO removal

    This specific bug is indirectly fixed upstream by UFO removal

    UFO stands for "UDP Fragmentation Offload" feature. It was removed in a branch merged in 5c3c608:

    $ git log -n 15 --oneline --graph 5c3c6081b246b05ee5bb2fc1759a7c0c6a0b7c3b

*   5c3c6081b246b05ee5bb2fc1759a7c0c6a0b7c3b Merge branch 'net-ufo-remove'
|\  
| * d9d30adf56777c402c0027c0e6ae21f17cc0a365 net: Kill NETIF_F_UFO and SKB_GSO_UDP.
| * 6800b2e040edda01f593aba28203c2ebf1679f4c inet: Remove software UFO fragmenting code.
| * 880388aa3c07fdea4f9b85e35641753017b1852f net: Remove all references to SKB_GSO_UDP.
| * 988cf74deb45bd6ee27433b7b5d1be6004d842b8 inet: Stop generating UFO packets.
| * 08a00fea6de277df12ccfadc21bf779df2e83705 net: Remove references to NETIF_F_UFO from ethtool.
| * d4c023f4f3dd96734ef53d4b588136a872300046 net: Remove references to NETIF_F_UFO in netdev_fix_features().
| * e078de03788353b220f3d501fc3607cc92db28c1 virtio_net: Remove references to NETIF_F_UFO.
| * 2082499a95ad31b88466e50f4c61513e3873ba9e dummy: Remove references to NETIF_F_UFO.
| * d591a1f3aad92ade4642e4173f4c368006c27f0f tun/tap: Remove references to NETIF_F_UFO.
| * fb652fdfe83710da0ca13448a41b7ed027d0a984 macvlan/macvtap: Remove NETIF_F_UFO advertisement.
| * 182e0b6b58463b85f9a34dd038847e4ab3604a4f ipvlan: Stop advertising NETIF_F_UFO support.
| * f9c45ae020bab86a820d8ef9097d021d5496b855 macb: Remove bogus reference to NETIF_F_UFO.
| * ed22e2f6b72de9dc2a2fe43cd553cf4d36f70785 s2io: Remove UFO support.
|/  
*   6093ec2dc313b57e6442c0d92acf137e60b42043 Merge branch 'xdp-redirect'

    This solution is not mutually exclusive with checking if offset is 0, as was done in 0:3.10.0-1062.el7 - removing UFO may get rid of problematic memcpy_fromiovecend() calls, but leave memcpy_fromiovecend() itself bugged.

    In any case UFO removal cannot be backported, as that would be a feature change.

  2. Commit 21226ab

    the buggy memcpy_fromiovecend() (and related functions) are fixed by:

    commit 21226ab
    Author: Al Viro <viro.org.uk>
    Date: Fri Nov 28 15:48:29 2014 -0500
    net: switch memcpy_fromiovec()/memcpy_fromiovecend() users to copy_from_iter()

    The commit mentioned doesn't really "fix" memcpy_fromiovecend(), but simply drops its usage, replacing it with a newer iov_iter interface (see https://lwn.net/Articles/625077/). In fact it's a part of a three-commits patch resulting in the eventual removal of memcpy_fromiovecend() function altogether:

    $ git log --date=iso -n 3 31a25fae85956e3a9c778141d29e5e803fb0b124

    commit 31a25fae85956e3a9c778141d29e5e803fb0b124
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   2014-11-28 15:53:57 -0500

    net: bury net/core/iovec.c - nothing in there is used anymore
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

commit f25dcc7687d42a72de18aa41b04990a24c9e77c7
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   2014-11-28 15:52:29 -0500

    tipc: tipc ->sendmsg() conversion
    
    This one needs to copy the same data from user potentially more than
    once.  Sadly, MTU changes can trigger that ;-/
    
    Cc: Jon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

commit 21226abb4e9f14d88238964d89b279e461ddc30c
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   2014-11-28 15:48:29 -0500

    net: switch memcpy_fromiovec()/memcpy_fromiovecend() users to copy_from_iter()
    
    That takes care of the majority of ->sendmsg() instances - most of them
    via memcpy_to_msg() or assorted getfrag() callbacks.  One place where we
    still keep memcpy_fromiovecend() is tipc - there we potentially read the
    same data over and over; separate patch, that...
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

    It's possible that the re-application of the CVE-2018-16885 patch in RH's kernel-0:3.10.0-1160.149.1.el7 kernel was the shift to iov_iter interface as well. Backporting this commit generates conflicts in nearly all modified files though, and solving them would require accounting for (at least) one prerequisite c0371da, which probably can't be backported in full. In short - it's not trivial and was left as an option to evaluate by the reviewers before putting effort into it.

  3. Guarding the vhost_chr_write_iter() call

    Sorry for inconvenience, I meant https://bugzilla.redhat.com/show_bug.cgi?id=1659451, but accidentally missed, we have similar issue where. And https://lists.openvz.org/pipermail/devel/2018-December/072970.html is a possible fix for it.

    The issue described in that mail is similar to what CVE-2018-16885 identifies only in the outcome of accessing iov array outside of bounds. The mechanism is entirely different and boils down to requesting memcpy_fromiovecend() to copy more bytes than the data chunks in iov contain. It may therefore be understood as improper use of memcpy_fromiovecend() and not necessarily a bug in the function itself. For the record, the patch given there is present in CBR 7.9 as well, in the same commit as the CVE-2018-16885 fix - c3ad1c3. See

    kernel-src-tree/drivers/vhost/net.c

    Lines 1437 to 1453 in c3ad1c3

    static ssize_t vhost_net_aio_write(struct kiocb *iocb,
    const struct iovec *from, unsigned long count, loff_t pos)
    {
    struct file *file = iocb->ki_filp;
    struct vhost_net *n = file->private_data;
    struct vhost_dev *dev = &n->dev;
    ssize_t len;
    len = iov_length(from, count);
    if (len < 0)
    return -EINVAL;
    if (len < sizeof(struct vhost_msg))
    return len;
    return vhost_chr_write_iter(dev, from);
    }

kABI check: passed

$ LOGS=ERROR CVE=CVE-batch-35 ./ninja.sh -d explain _kabi_check_kernel__x86_64--test--ciqcbr7_9-CVE-batch-35
[0/1] kabi_check_kernel	Check ABI of kernel [ciqcbr7_9-CVE-batch-35]	_kabi_check_kernel__x86_64--test--ciqcbr7_9-CVE-batch-35
ninja explain: output state/kernels/ciqcbr7_9-CVE-batch-35/x86_64/kabi_checked doesn't exist
ninja explain: state/kernels/ciqcbr7_9-CVE-batch-35/x86_64/kabi_checked is dirty
+ dist_git_version=el-7.9
+ local_version=ciqcbr7_9-CVE-batch-35
+ arch=x86_64
+ user=pvts
+ buildmachine=x86_64--build--ciqcbr7_9
+ virsh_timeout=600
+ ssh_daemon_wait=20
+ src_dir=/mnt/code/kernel-dist-git-el-7.9
+ build_dir=/mnt/build_files/kernel-src-tree-ciqcbr7_9-CVE-batch-35
+ sudo chmod +x /data/src/ctrliq-github-haskell/kernel-dist-git-el-7.9/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--ciqcbr7_9 ''\''/mnt/code/kernel-dist-git-el-7.9/SOURCES/check-kabi'\'' -k '\''/mnt/code/kernel-dist-git-el-7.9/SOURCES/Module.kabi_x86_64'\'' -s '\''/mnt/build_files/kernel-src-tree-ciqcbr7_9-CVE-batch-35/Module.symvers'\'''
kABI check passed
+ touch state/kernels/ciqcbr7_9-CVE-batch-35/x86_64/kabi_checked

Boot test: passed

boot-test.log

Kselftests: passed relative

Reference

kselftests–ciqcbr7_9–run1.log

Patch

kselftests–ciqcbr7_9-CVE-batch-35–run1.log
kselftests–ciqcbr7_9-CVE-batch-35–run2.log

Comparison

The tests results were compared manually with meld. No results differences were found.

pvts-mat added 2 commits June 17, 2026 02:27
@pvts-mat
nfsd: fix heap overflow in NFSv4.0 LOCK replay cache
eeeda5b 
jira VULN-180160
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 CBR 7.9
  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
sctp: avoid NULL dereference when chunk data buffer is missing
9f7bcac 
jira VULN-176137
cve CVE-2025-40240
commit-author Alexey Simakov <bigalex934@gmail.com>
commit 441f064
upstream-diff Same change as in upstream, except for ciqcbr7_9's
  SCTP_INC_STATS_BH macro instead of upstream's __SCTP_INC_STATS. It's
  the same macro, renamed on upstream in
  13415e4 ("net: snmp: kill STATS_BH
  macros")

chunk->skb pointer is dereferenced in the if-block where it's supposed
to be NULL only.

chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_list
instead and do it just before replacing chunk->skb. We're sure that
otherwise chunk->skb is non-NULL because of outer if() condition.

Fixes: 90017ac ("sctp: Add GSO support")
	Signed-off-by: Alexey Simakov <bigalex934@gmail.com>
	Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Link: https://patch.msgid.link/20251021130034.6333-1-bigalex934@gmail.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 441f064)
	Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
@pvts-mat pvts-mat force-pushed the CVE-batch-35_ciqcbr7_9 branch from d83471a to 9f7bcac Compare June 17, 2026 00:27
@github-actions

github-actions Bot commented Jun 17, 2026

Copy link
Copy Markdown

🤖 Validation Checks In Progress Workflow run: https://github.com/ctrliq/kernel-src-tree/actions/runs/27696065423

@github-actions

github-actions Bot commented Jun 17, 2026

Copy link
Copy Markdown

🔍 Interdiff Analysis

  • ⚠️ PR commit eeeda5b8cde4 (nfsd: fix heap overflow in NFSv4.0 LOCK replay cache) → upstream 5133b61aaf43
    Differences found:
================================================================================
*    DELTA DIFFERENCES - code changes that differ between the patches          *
================================================================================

--- b/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -4469,10 +4469,8 @@
 		int len = xdr->buf->len - post_err_offset;
 
 		so->so_replay.rp_status = op->status;
-		if (len <= NFSD4_REPLAY_ISIZE) {
-			so->so_replay.rp_buflen = len;
-			read_bytes_from_xdr_buf(xdr->buf,
-						post_err_offset,
+		so->so_replay.rp_buflen = len;
+		read_bytes_from_xdr_buf(xdr->buf, post_err_offset,
 						so->so_replay.rp_buf, len);
 		} else {
 			so->so_replay.rp_buflen = 0;

################################################################################
!    REJECTED PATCH2 HUNKS - could not be compared; manual review needed       !
################################################################################

--- b/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -6281,8 +6281,10 @@
 		int len = xdr->buf->len - (op_status_offset + XDR_UNIT);
 
 		so->so_replay.rp_status = op->status;
-		so->so_replay.rp_buflen = len;
-		read_bytes_from_xdr_buf(xdr->buf, op_status_offset + XDR_UNIT,
+		if (len <= NFSD4_REPLAY_ISIZE) {
+			so->so_replay.rp_buflen = len;
+			read_bytes_from_xdr_buf(xdr->buf,
+						op_status_offset + XDR_UNIT,
 						so->so_replay.rp_buf, len);
 	}
 status:

================================================================================
*    CONTEXT DIFFERENCES - surrounding code differences between the patches    *
================================================================================

--- b/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -4466,8 +4467,8 @@
 
 		so->so_replay.rp_status = op->status;
 		so->so_replay.rp_buflen = len;
-		read_bytes_from_xdr_buf(xdr->buf, post_err_offset,
+		read_bytes_from_xdr_buf(xdr->buf, op_status_offset + XDR_UNIT,
 						so->so_replay.rp_buf, len);
 	}
 status:
-	/* Note that op->status is already in network byte order: */
+	op->status = nfsd4_map_status(op->status,
  • ⚠️ PR commit 9f7bcacb7ee1 (sctp: avoid NULL dereference when chunk data buffer is missing) → upstream 441f0647f767
    Differences found:
================================================================================
*    DELTA DIFFERENCES - code changes that differ between the patches          *
================================================================================

--- b/net/sctp/inqueue.c
+++ b/net/sctp/inqueue.c
@@ -187,12 +187,17 @@
 			/* skbs with "cover letter" */
 			if (chunk->head_skb && chunk->skb->data_len == chunk->skb->len) {
 				if (WARN_ON(!skb_shinfo(chunk->skb)->frag_list)) {
-					SCTP_INC_STATS_BH(dev_net(chunk->skb->dev),
-							  SCTP_MIB_IN_PKT_DISCARDS);
+					__SCTP_INC_STATS(dev_net(chunk->skb->dev),
+							 SCTP_MIB_IN_PKT_DISCARDS);
 					sctp_chunk_free(chunk);
 					goto next_chunk;
 				}
 				chunk->skb = skb_shinfo(chunk->skb)->frag_list;
+
+			if (WARN_ON(!chunk->skb)) {
+				SCTP_INC_STATS_BH(dev_net(chunk->skb->dev), SCTP_MIB_IN_PKT_DISCARDS);
+				sctp_chunk_free(chunk);
+				goto next_chunk;
 			}
 		}
 

################################################################################
!    REJECTED PATCH2 HUNKS - could not be compared; manual review needed       !
################################################################################

--- b/net/sctp/inqueue.c
+++ b/net/sctp/inqueue.c
@@ -177,11 +183,6 @@
 			/* skbs with "cover letter" */
 			if (chunk->head_skb && chunk->skb->data_len == chunk->skb->len)
 				chunk->skb = skb_shinfo(chunk->skb)->frag_list;
-
-			if (WARN_ON(!chunk->skb)) {
-				__SCTP_INC_STATS(dev_net(chunk->skb->dev), SCTP_MIB_IN_PKT_DISCARDS);
-				sctp_chunk_free(chunk);
-				goto next_chunk;
 			}
 		}
 

================================================================================
*    CONTEXT DIFFERENCES - surrounding code differences between the patches    *
================================================================================

--- b/net/sctp/inqueue.c
+++ b/net/sctp/inqueue.c
@@ -189,7 +173,7 @@
 				chunk->skb = skb_shinfo(chunk->skb)->frag_list;
 
 			if (WARN_ON(!chunk->skb)) {
-				SCTP_INC_STATS_BH(dev_net(chunk->skb->dev), SCTP_MIB_IN_PKT_DISCARDS);
+				__SCTP_INC_STATS(dev_net(chunk->skb->dev), SCTP_MIB_IN_PKT_DISCARDS);
 				sctp_chunk_free(chunk);
 				goto next_chunk;
 			}

This is an automated interdiff check for backported commits.

@github-actions

github-actions Bot commented Jun 17, 2026

Copy link
Copy Markdown

JIRA PR Check Results

2 commit(s) with issues found:

Commit 9f7bcacb7ee1

Summary: sctp: avoid NULL dereference when chunk data buffer is missing

❌ Errors:

  • VULN-176137: Status is 'To Do', expected 'In Progress'

⚠️ Warnings:

  • VULN-176137: No time logged - please log time manually

Commit eeeda5b8cde4

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

❌ Errors:

  • VULN-180160: Status is 'To Do', expected 'In Progress'

⚠️ Warnings:

  • VULN-180160: No time logged - please log time manually

Summary: Checked 2 commit(s) total.

@github-actions

github-actions Bot commented Jun 17, 2026

Copy link
Copy Markdown

❌ Validation checks completed with issues View full results: https://github.com/ctrliq/kernel-src-tree/actions/runs/27696065423

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@pvts-mat