Skip to content

[CBR 7.9] CVE-2025-39955, CVE-2025-38718, CVE-2025-39973, CVE-2025-39971, CVE-2025-40186#1284

Open
pvts-mat wants to merge 6 commits into
ctrliq:ciqcbr7_9from
pvts-mat:CVE-batch-34_ciqcbr7_9
Open

[CBR 7.9] CVE-2025-39955, CVE-2025-38718, CVE-2025-39973, CVE-2025-39971, CVE-2025-40186#1284
pvts-mat wants to merge 6 commits into
ctrliq:ciqcbr7_9from
pvts-mat:CVE-batch-34_ciqcbr7_9

Conversation

@pvts-mat
Copy link
Copy Markdown
Contributor

@pvts-mat pvts-mat commented May 30, 2026

[CBR 7.9]

CVE-2025-39955 VULN-158526
CVE-2025-38718 VULN-136336
CVE-2025-39973 VULN-158762
CVE-2025-39971 VULN-158746
CVE-2025-40186  

Commits

CVE-2025-39955 (+ CVE-2025-40186)

tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().

jira VULN-158526
cve CVE-2025-39955
commit-author Kuniyuki Iwashima <kuniyu@google.com>
commit 45c8a6cc2bcd780e634a6ba8e46bffbdf1fc5c01
upstream-diff Solved context conflicts stemming from the lack of
  7db92362d2fee5887f6b0c41653b8c9f8f5d6020 ("fix potential double free
  issue for fastopen_req"). No actual diffs from the upstream

This backport was problematic because of the very non-local nature of the fix (and its bugfix) coupled with large discrepancies between the upstream and CBR 7.9 implementation of the TCP Fast Open feature, which necessitated detailed understanding of the TFO connection initiation mechanics.

The bugfix 2e7cbbb does not apply to this backport.

The bug occurs during the initial, three-way handshake (3WHS) stage of a TCP connection, on the server's side.

    Client                                        Server
    State      Client                 Server      State
                  |                      |         
                  |                      |      TCP_CLOSED
                  |        SYN           |        
                  |--------------------->|
 TCP_SYN_SENT     |      SYN+ACK         |     TCP_SYN_RECV
                  |<---------------------|
TCP_ESTABLISHED   |        ACK           |
                  |--------------------->|
                  |                      |    TCP_ESTABLISHED
                  V                      V

The TCP Fast Open (TFO) is an enhancement of the TCP protocol, which allows both sides to exchange data before the 3WHS was completed, by including data in the SYN and/or SYN+ACK messages. This greatly reduces latency for short connections, saving a full round-trip time (RTT) reserved previously for the initial handshake only. See RFC 7413 for details.

On the server's side the handshake involves two sockets: a listening socket and a child socket. The listening socket lives as long as the server process (typically) and it's always in the TCP_LISTEN state, tasked with dispatching the connection requests. Upon receiving the SYN message it spawns a child socket (or retrieves one of the child sockets already created for the identified sender) which handles the rest of the handshake. The fastopen_rsk ("fastopen request socket") field mentioned in the CVE-2025-39955 fixing commit's message belongs to the child socket and represents the socket of the client it's connected to. It's used to track connection parameters. This field is supposed to be non-NULL if, and only if, the 3WHS with the client using TFO feature has not been completed yet. From the 1046716's message, of one of the commits implementing TFO:

"fastopen_rsk" in tcp_sock - for a big socket to access its
request_sock for retransmission and ack processing purpose. It is
non-NULL iff 3WHS not completed.

The CVE-2025-39955 bug stems from the violation of this invariant, that is from having non-NULL fastopen_rsk in a child socket which was disconnected from the requester, so having the ongoing 3WHS effectively "completed".

The warning mentioned in the CVE fix message is triggered in CBR 7.9 by this code fragment:

kernel-src-tree/net/ipv4/tcp_timer.c

Lines 352 to 353 in 3cc43ad

WARN_ON_ONCE(sk->sk_state != TCP_SYN_RECV &&
sk->sk_state != TCP_FIN_WAIT1);

which means that either TCP_FIN_WAIT1 or TCP_SYN_RECV state of the child socket is expected when its fastopen_rsk field is non-NULL, reflecting the assumed invariant. At this moment, however, it was a different, non-TFO connection, for which the child socket was reused, and the fastopen_rsk field was left as uncleaned garbage from the previous one. The 45c8a6c commit message may be misleading in saying

syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk
in the TCP_ESTABLISHED state. [0]

as it suggests the problem lies in fastopen_rsk surviving the 3WHS completion resulting in the TCP_ESTABLISHED state, while the problem lies in fastopen_rsk surviving TCP disconnection and living to another one handled by the same socket object, which is an error regardless of the state the new connection found itself in at the moment of timer execution, it being TCP_ESTABLISHED only conveniently uncovering the bug with kernel's warning.

The function designated for setting fastopen_rsk to NULL is reqsk_fastopen_remove(). From its documentation:

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

Lines 135 to 138 in 3cc43ad

* This function is called to set a Fast Open socket's "fastopen_rsk" field
* to NULL when a TFO socket no longer needs to access the request_sock.
* This happens only after 3WHS has been either completed or aborted (e.g.,
* RST is received).

Calling it in the tcp_disconnet() procedure was proposed as the fix for the CVE-2025-39955 problem in 45c8a6c.

As it turned out, putting reqsk_fastopen_remove() on this code path conflicted with a different one already doing that, which resulted in a bugfix 2e7cbbb removing reqsk_fastopen_remove() call from the tcp_conn_request() function. This was assigned its own CVE-2025-40186.

In CBR 7.9 codebase this call doesn't exist. It was introduced in 9d3e136 which was backported only partially, with changes to the net/ipv4/tcp_input.c omitted (see c3ad1c3). To make sure it's not to be found anywhere else - which may be probable given its discrepancies from the upstream - a balance of reqsk_fastopen_remove() calls was made for ciqcbr7_9 and the upstream at the moment right before the bugfix (2e7cbbb~1), putting the corresponding calls next to each other.

`ciqcbr7_9` 2e7cbbb~1 Comment
`net/ipv4/tcp.c:3061` `net/ipv4/tcp.c:5000`  
`net/ipv4/tcp.c:2166` `net/ipv4/tcp.c:3282`  
- `net/ipv4/tcp.c:3475` Call introduced in the upstream by the CVE-2025-39955 patch
`net/ipv4/tcp_input.c:5899` `net/ipv4/tcp_input.c:6882` A single call in upstream corresponds to two different calls in `ciqcbr7_9` due to non-backported common code refactor
`net/ipv4/tcp_input.c:5969` `net/ipv4/tcp_input.c:6882`  
- `net/ipv4/tcp_input.c:7512` Call introduced in 9d3e136 and removed in the bugfix 2e7cbbb
`net/ipv4/tcp_minisocks.c:798` `net/ipv4/tcp_minisocks.c:951`  

What's important in the table above is that no reqsk_fastopen_remove() call can be found in ciqcbr7_9 which didn't have a corresponding reqsk_fastopen_remove() call in the upstream, eliminating a possibility that the extra reqsk_fastopen_remove() call to remove in the bugfix might have been in a different place than tcp_conn_request().

The bugfix commit 2e7cbbb says:

Note that other callers make sure tp->fastopen_rsk is not NULL.

This comment is important because it justifies the scope of the bugfix, which doesn't include any other reqsk_fastopen_remove() calls, a scope potentially different in CBR 7.9. However, the condition holds for CBR 7.9 as well. Here are all the function calls in CBR 7.9:

kernel-src-tree/net/ipv4/tcp.c

Lines 2165 to 2166 in 3cc43ad

if (req != NULL)
reqsk_fastopen_remove(sk, req, false);

kernel-src-tree/net/ipv4/tcp.c

Lines 3060 to 3061 in 3cc43ad

if (req != NULL)
reqsk_fastopen_remove(sk, req, false);

kernel-src-tree/net/ipv4/tcp_input.c

Lines 5896 to 5899 in 3cc43ad

if (req) {
synack_stamp = tcp_rsk(req)->snt_synack;
tp->total_retrans = req->num_retrans;
reqsk_fastopen_remove(sk, req, false);

kernel-src-tree/net/ipv4/tcp_input.c

Lines 5959 to 5969 in 3cc43ad

if (req != NULL) {
/* Return RST if ack_seq is invalid.
* Note that RFC793 only says to generate a
* DUPACK for it but for TCP Fast Open it seems
* better to treat this case like TCP_SYN_RECV
* above.
*/
if (!acceptable)
return 1;
/* We no longer need the request sock. */
reqsk_fastopen_remove(sk, req, false);

The last call, in tcp_check_req()

kernel-src-tree/net/ipv4/tcp_minisocks.c

Line 798 in 3cc43ad

reqsk_fastopen_remove(sk, req, true);

is not guarded by a NULL check. However, the calls to tcp_check_req() are (and the req argument variable doesn't change its value across tcp_check_req() body):

kernel-src-tree/net/ipv4/tcp_input.c

Lines 5869 to 5874 in 3cc43ad

req = tp->fastopen_rsk;
if (req != NULL) {
WARN_ON_ONCE(sk->sk_state != TCP_SYN_RECV &&
sk->sk_state != TCP_FIN_WAIT1);
if (tcp_check_req(sk, skb, req, NULL, true) == NULL)

kernel-src-tree/net/ipv4/tcp_ipv4.c

Lines 1453 to 1454 in 3cc43ad

if (req)
return tcp_check_req(sk, skb, req, prev, false);

kernel-src-tree/net/ipv6/tcp_ipv6.c

Lines 1018 to 1019 in 3cc43ad

if (req)
return tcp_check_req(sk, skb, req, prev, false);

This provides a sufficient argument for not including the bugfix 2e7cbbb in the CVE-2025-39955 fix for CBR 7.9 and marking CVE-2025-40186 as not affecting CBR 7.9.

CVE-2025-38718

sctp: linearize cloned gso packets in sctp_rcv

jira VULN-136336
cve CVE-2025-38718
commit-author Xin Long <lucien.xin@gmail.com>
commit fd60d8a086191fe33c2d719732d2482052fa6805
upstream-diff Accounted for the missing
  1dd27cde30e85774c77349c804229431616d594a ("net: use skb_is_gso_sctp()
  instead of open-coding"). The upstream's `is_gso' is a stronger, not
  equivalent condition to ciqcbr7_9's `skb_shinfo(skb)->gso_type &
  SKB_GSO_SCTP'. It's equivalent to `skb_is_gso(skb) &&
  skb_is_gso_sctp(skb)', while the ciqcbr7_9's version is equivalent to
  just `skb_is_gso_sctp(skb)' (the `skb_is_gso(skb)' part was added
  later by 1dd27cde3). Between the alignment of the condition and the
  alignment of the backport - in relation to the upstream - the former
  was chosen because it results in more correct code.

Commit 1dd27cd was considered as prerequisite for this bugfix. It actually cherry-picks cleanly (though doesn't compile without adding some headers), except for the conflicts in the documentation file Documentation/networking/segmentation-offloads.txt, but given CBR 7.9's age and the essentionality of some of the files it modifies a more conservative, less invasive solution was chosen instead. Can be altered on demand.

CVE-2025-39973

i40e: validate ring_len parameter against hardware-specific values

jira VULN-158762
cve-bf CVE-2025-39973
commit-author Gregory Herrero <gregory.herrero@oracle.com>
commit 69942834215323cd9131db557091b4dec43f19c5
upstream-diff Context conflict resolved in
  drivers/net/ethernet/intel/i40e/i40e.h

i40e: add validation for ring_len param

jira VULN-158762
cve CVE-2025-39973
commit-author Lukasz Czapnik <lukasz.czapnik@intel.com>
commit 55d225670def06b01af2e7a5e0446fbe946289e8

i40e: increase max descriptors for XL710

jira VULN-158762
cve-pre CVE-2025-39973
commit-author Justin Bronder <jsbronder@cold-front.org>
commit aa6908ca3bd1e713fd6cd8d7193a008f060bf7d9

CVE-2025-39971

i40e: fix idx validation in config queues msg

jira VULN-158746
cve CVE-2025-39971
commit-author Lukasz Czapnik <lukasz.czapnik@intel.com>
commit f1ad24c5abe1eaef69158bac1405a74b3c365115
upstream-diff Context conflict resolved (missing commit
  230f3d53a5477bf8b04e649dca67da85635cd1eb ("i40e: remove i40e_status"))

kABI check: passed

[0/1] kabi_check_kernel	Check ABI of kernel [ciqcbr7_9-CVE-batch-34]	_kabi_check_kernel__x86_64--test--ciqcbr7_9-CVE-batch-34
+ dist_git_version=el-7.9
+ local_version=ciqcbr7_9-CVE-batch-34
+ 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-34
+ 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-34/Module.symvers'\'''
kABI check passed
+ touch state/kernels/ciqcbr7_9-CVE-batch-34/x86_64/kabi_checked

Boot test: passed

boot-test.log

Kselftests: passed relative

Reference

kselftests–ciqcbr7_9–run1.log
kselftests–ciqcbr7_9–run2.log

Patch

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

Comparison

Files compared with meld, no differences in the results found.

pvts-mat added 6 commits May 31, 2026 01:46
@pvts-mat
i40e: fix idx validation in config queues msg
a568d80 
jira VULN-158746
cve CVE-2025-39971
commit-author Lukasz Czapnik <lukasz.czapnik@intel.com>
commit f1ad24c
upstream-diff Context conflict resolved (missing commit
  230f3d5 ("i40e: remove i40e_status"))

Ensure idx is within range of active/initialized TCs when iterating over
vf->ch[idx] in i40e_vc_config_queues_msg().

Fixes: c27eac4 ("i40e: Enable ADq and create queue channel/s on VF")
	Cc: stable@vger.kernel.org
	Signed-off-by: Lukasz Czapnik <lukasz.czapnik@intel.com>
	Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
	Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
	Reviewed-by: Simon Horman <horms@kernel.org>
	Tested-by: Kamakshi Nellore <nellorex.kamakshi@intel.com> (A Contingent Worker at Intel)
	Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
(cherry picked from commit f1ad24c)
	Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
@pvts-mat
i40e: increase max descriptors for XL710
c65b682 
jira VULN-158762
cve-pre CVE-2025-39973
commit-author Justin Bronder <jsbronder@cold-front.org>
commit aa6908c

In Tables 8-12 and 8-22 in the X710/XXV710/XL710 datasheet, the QLEN
description states that the maximum size of the descriptor queue is 8k
minus 32, or 8160.

	Signed-off-by: Justin Bronder <jsbronder@cold-front.org>
	Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
	Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
	Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Link: https://lore.kernel.org/r/20231113231047.548659-2-anthony.l.nguyen@intel.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit aa6908c)
	Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
@pvts-mat
i40e: add validation for ring_len param
7c06892 
jira VULN-158762
cve CVE-2025-39973
commit-author Lukasz Czapnik <lukasz.czapnik@intel.com>
commit 55d2256

The `ring_len` parameter provided by the virtual function (VF)
is assigned directly to the hardware memory context (HMC) without
any validation.

To address this, introduce an upper boundary check for both Tx and Rx
queue lengths. The maximum number of descriptors supported by the
hardware is 8k-32.
Additionally, enforce alignment constraints: Tx rings must be a multiple
of 8, and Rx rings must be a multiple of 32.

Fixes: 5c3c48a ("i40e: implement virtual device interface")
	Cc: stable@vger.kernel.org
	Signed-off-by: Lukasz Czapnik <lukasz.czapnik@intel.com>
	Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
	Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
	Reviewed-by: Simon Horman <horms@kernel.org>
	Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
	Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
(cherry picked from commit 55d2256)
	Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
@pvts-mat
i40e: validate ring_len parameter against hardware-specific values
c0bf37d 
jira VULN-158762
cve-bf CVE-2025-39973
commit-author Gregory Herrero <gregory.herrero@oracle.com>
commit 6994283
upstream-diff Context conflict resolved in
  drivers/net/ethernet/intel/i40e/i40e.h

The maximum number of descriptors supported by the hardware is
hardware-dependent and can be retrieved using
i40e_get_max_num_descriptors(). Move this function to a shared header
and use it when checking for valid ring_len parameter rather than using
hardcoded value.

By fixing an over-acceptance issue, behavior change could be seen where
ring_len could now be rejected while configuring rx and tx queues if its
size is larger than the hardware-dependent maximum number of
descriptors.

Fixes: 55d2256 ("i40e: add validation for ring_len param")
	Signed-off-by: Gregory Herrero <gregory.herrero@oracle.com>
	Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
	Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
	Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
(cherry picked from commit 6994283)
	Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
@pvts-mat
sctp: linearize cloned gso packets in sctp_rcv
5a66caf 
jira VULN-136336
cve CVE-2025-38718
commit-author Xin Long <lucien.xin@gmail.com>
commit fd60d8a
upstream-diff Accounted for the missing
  1dd27cd ("net: use skb_is_gso_sctp()
  instead of open-coding"). The upstream's `is_gso' is a stronger, not
  equivalent condition to ciqcbr7_9's `skb_shinfo(skb)->gso_type &
  SKB_GSO_SCTP'. It's equivalent to `skb_is_gso(skb) &&
  skb_is_gso_sctp(skb)', while the ciqcbr7_9's version is equivalent to
  just `skb_is_gso_sctp(skb)' (the `skb_is_gso(skb)' part was added
  later by 1dd27cd). Between the alignment of the condition and the
  alignment of the backport - in relation to the upstream - the former
  was chosen because it results in more correct code.

A cloned head skb still shares these frag skbs in fraglist with the
original head skb. It's not safe to access these frag skbs.

syzbot reported two use-of-uninitialized-memory bugs caused by this:

  BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211
   sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211
   sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998
   sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88
   sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331
   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122
   __release_sock+0x1da/0x330 net/core/sock.c:3106
   release_sock+0x6b/0x250 net/core/sock.c:3660
   sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360
   sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885
   sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031
   inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851
   sock_sendmsg_nosec net/socket.c:718 [inline]

and

  BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987
   sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987
   sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88
   sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331
   sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148
   __release_sock+0x1d3/0x330 net/core/sock.c:3213
   release_sock+0x6b/0x270 net/core/sock.c:3767
   sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367
   sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886
   sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032
   inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851
   sock_sendmsg_nosec net/socket.c:712 [inline]

This patch fixes it by linearizing cloned gso packets in sctp_rcv().

Fixes: 90017ac ("sctp: Add GSO support")
	Reported-by: syzbot+773e51afe420baaf0e2b@syzkaller.appspotmail.com
	Reported-by: syzbot+70a42f45e76bede082be@syzkaller.appspotmail.com
	Signed-off-by: Xin Long <lucien.xin@gmail.com>
	Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Link: https://patch.msgid.link/dd7dc337b99876d4132d0961f776913719f7d225.1754595611.git.lucien.xin@gmail.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit fd60d8a)
	Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
@pvts-mat
tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().
ffa79e2 
jira VULN-158526
cve CVE-2025-39955
commit-author Kuniyuki Iwashima <kuniyu@google.com>
commit 45c8a6c
upstream-diff Solved context conflicts stemming from the lack of
  7db9236 ("fix potential double free
  issue for fastopen_req"). No actual diffs from the upstream

syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk
in the TCP_ESTABLISHED state. [0]

syzbot reused the server-side TCP Fast Open socket as a new client before
the TFO socket completes 3WHS:

  1. accept()
  2. connect(AF_UNSPEC)
  3. connect() to another destination

As of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes
it to TCP_CLOSE and makes connect() possible, which restarts timers.

Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the
retransmit timer triggered the warning and the intended packet was not
retransmitted.

Let's call reqsk_fastopen_remove() in tcp_disconnect().

[0]:
WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Modules linked in:
CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 ctrliq#62 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e
RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293
RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017
RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400
RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8
R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540
R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0
FS:  0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0
Call Trace:
 <IRQ>
 tcp_write_timer (net/ipv4/tcp_timer.c:738)
 call_timer_fn (kernel/time/timer.c:1747)
 __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372)
 timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135)
 tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035)
 __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1))
 tmigr_handle_remote (kernel/time/timer_migration.c:1096)
 handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580)
 irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696)
 sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))
 </IRQ>

Fixes: 8336886 ("tcp: TCP Fast Open Server - support TFO listeners")
	Reported-by: syzkaller <syzkaller@googlegroups.com>
	Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20250915175800.118793-2-kuniyu@google.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 45c8a6c)
	Signed-off-by: Marcin Wcisło <marcin.wcislo@conclusive.pl>
@pvts-mat pvts-mat marked this pull request as ready for review May 30, 2026 23:48
@github-actions
Copy link
Copy Markdown

github-actions Bot commented Jun 1, 2026

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

@github-actions
Copy link
Copy Markdown

github-actions Bot commented Jun 1, 2026

🔍 Upstream Linux Kernel Commit Check

  • ⚠️ PR commit ffa79e2fa2d2 (tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().) references upstream commit
    45c8a6cc2bcd which has been referenced by a Fixes: tag in the upstream
    Linux kernel:
    2e7cbbbe3d61 tcp: Don't call reqsk_fastopen_remove() in tcp_conn_request(). (Kuniyuki Iwashima) (CVE-2025-40186)

This is an automated message from the kernel commit checker workflow.

@github-actions
Copy link
Copy Markdown

github-actions Bot commented Jun 1, 2026

🔍 Interdiff Analysis

  • ⚠️ PR commit a568d80ab0d3 (i40e: fix idx validation in config queues msg) → upstream f1ad24c5abe1
    Differences found:
################################################################################
!    REJECTED PATCH2 HUNKS - could not be compared; manual review needed       !
################################################################################

--- b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -2395,7 +2395,7 @@
 		}
 
 		if (vf->adq_enabled) {
-			if (idx >= ARRAY_SIZE(vf->ch)) {
+			if (idx >= vf->num_tc) {
 				aq_ret = -ENODEV;
 				goto error_param;
 			}
@@ -2416,7 +2416,7 @@
 		 * to its appropriate VSIs based on TC mapping
 		 */
 		if (vf->adq_enabled) {
-			if (idx >= ARRAY_SIZE(vf->ch)) {
+			if (idx >= vf->num_tc) {
 				aq_ret = -ENODEV;
 				goto error_param;
 			}

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

--- b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -2203,5 +2203,5 @@
 		if (vf->adq_enabled) {
 			if (idx >= ARRAY_SIZE(vf->ch)) {
-				aq_ret = I40E_ERR_NO_AVAILABLE_VSI;
+				aq_ret = -ENODEV;
 				goto error_param;
 			}
@@ -2227,5 +2418,5 @@
 		if (vf->adq_enabled) {
 			if (idx >= ARRAY_SIZE(vf->ch)) {
-				aq_ret = I40E_ERR_NO_AVAILABLE_VSI;
+				aq_ret = -ENODEV;
 				goto error_param;
 			}
  • ⚠️ PR commit c65b682db6a1 (i40e: increase max descriptors for XL710) → upstream aa6908ca3bd1
    Differences found:
================================================================================
*    CONTEXT DIFFERENCES - surrounding code differences between the patches    *
================================================================================

--- b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1901,6 +1901,6 @@
 		drvinfo->n_priv_flags += I40E_GL_PRIV_FLAGS_STR_LEN;
 }
 
 static void i40e_get_ringparam(struct net_device *netdev,
-			       struct ethtool_ringparam *ring)
-{
+			       struct ethtool_ringparam *ring,
+			       struct kernel_ethtool_ringparam *kernel_ring,
@@ -1932,5 +2045,5 @@
-static int i40e_set_ringparam(struct net_device *netdev,
-			      struct ethtool_ringparam *ring)
+			      struct kernel_ethtool_ringparam *kernel_ring,
+			      struct netlink_ext_ack *extack)
 {
 	struct i40e_ring *tx_rings = NULL, *rx_rings = NULL;
 	struct i40e_netdev_priv *np = netdev_priv(netdev);
  • ⚠️ PR commit c0bf37d3bf9b (i40e: validate ring_len parameter against hardware-specific values) → upstream 699428342153
    Differences found:
================================================================================
*    DELTA DIFFERENCES - code changes that differ between the patches          *
================================================================================

--- b/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -1111,14 +1111,2 @@
 				      bool add);
-
-static inline u32 i40e_get_max_num_descriptors(const struct i40e_pf *pf)
-{
-	const struct i40e_hw *hw = &pf->hw;
-
-	switch (hw->mac.type) {
-	case I40E_MAC_XL710:
-		return I40E_MAX_NUM_DESCRIPTORS_XL710;
-	default:
-		return I40E_MAX_NUM_DESCRIPTORS;
-	}
-}
 #endif /* _I40E_H_ */

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

--- b/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -1424,2 +1424,13 @@
 
+static inline u32 i40e_get_max_num_descriptors(const struct i40e_pf *pf)
+{
+	const struct i40e_hw *hw = &pf->hw;
+
+	switch (hw->mac.type) {
+	case I40E_MAC_XL710:
+		return I40E_MAX_NUM_DESCRIPTORS_XL710;
+	default:
+		return I40E_MAX_NUM_DESCRIPTORS;
+	}
+}
 #endif /* _I40E_H_ */

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

--- b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1917,5 +2026,5 @@
 }
 
 static void i40e_get_ringparam(struct net_device *netdev,
-			       struct ethtool_ringparam *ring)
-{
+			       struct ethtool_ringparam *ring,
+			       struct kernel_ethtool_ringparam *kernel_ring,
  • ⚠️ PR commit 5a66cafa7176 (sctp: linearize cloned gso packets in sctp_rcv) → upstream fd60d8a08619
    Differences found:
================================================================================
*    DELTA DIFFERENCES - code changes that differ between the patches          *
================================================================================

--- b/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -130,8 +130,7 @@
 	 * it's better to just linearize it otherwise crc computing
 	 * takes longer.
 	 */
-	if (((!(skb_is_gso(skb) && (skb_shinfo(skb)->gso_type & SKB_GSO_SCTP))
-	      || skb_cloned(skb)) &&
+	if ((!(skb_shinfo(skb)->gso_type & SKB_GSO_SCTP) &&
 	     skb_linearize(skb)) ||
 	    !pskb_may_pull(skb, sizeof(struct sctphdr)))
 		goto discard_it;

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

--- b/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -117,7 +117,7 @@
 	 * it's better to just linearize it otherwise crc computing
 	 * takes longer.
 	 */
-	if ((!is_gso && skb_linearize(skb)) ||
+	if (((!is_gso || skb_cloned(skb)) && skb_linearize(skb)) ||
 	    !pskb_may_pull(skb, sizeof(struct sctphdr)))
 		goto discard_it;
 

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

--- b/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -115,6 +115,5 @@
 	 * takes longer.
 	 */
-	if ((!(skb_shinfo(skb)->gso_type & SKB_GSO_SCTP) &&
-	     skb_linearize(skb)) ||
+	if ((!is_gso && skb_linearize(skb)) ||
 	    !pskb_may_pull(skb, sizeof(struct sctphdr)))
 		goto discard_it;
  • ⚠️ PR commit ffa79e2fa2d2 (tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().) → upstream 45c8a6cc2bcd
    Differences found:
================================================================================
*    DELTA DIFFERENCES - code changes that differ between the patches          *
================================================================================

--- b/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2246,11 +2245,6 @@
 	dst_release(sk->sk_rx_dst);
 	sk->sk_rx_dst = NULL;
 
-	req = rcu_dereference_protected(tp->fastopen_rsk,
-					lockdep_sock_is_held(sk));
-	if (req)
-		reqsk_fastopen_remove(sk, req, false);
-
 	WARN_ON(inet->inet_num && !icsk->icsk_bind_hash);
 
 	sk->sk_error_report(sk);

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

--- b/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3327,6 +3327,7 @@
 	struct inet_connection_sock *icsk = inet_csk(sk);
 	struct tcp_sock *tp = tcp_sk(sk);
 	int old_state = sk->sk_state;
+	struct request_sock *req;
 	u32 seq;
 
 	if (old_state != TCP_CLOSE)
@@ -3442,6 +3443,10 @@
 
 
 	/* Clean up fastopen related fields */
+	req = rcu_dereference_protected(tp->fastopen_rsk,
+					lockdep_sock_is_held(sk));
+	if (req)
+		reqsk_fastopen_remove(sk, req, false);
 	tcp_free_fastopen_req(tp);
 	inet_clear_bit(DEFER_CONNECT, sk);
 	tp->fastopen_client_fail = 0;

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

--- b/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2188,5 +2189,5 @@
 	struct tcp_sock *tp = tcp_sk(sk);
-	int err = 0;
 	int old_state = sk->sk_state;
+	u32 seq;
 
 	if (old_state != TCP_CLOSE)
@@ -2242,4 +3378,6 @@
 
-	WARN_ON(inet->inet_num && !icsk->icsk_bind_hash);
 
-	sk->sk_error_report(sk);
+	/* Clean up fastopen related fields */
+	tcp_free_fastopen_req(tp);
+	inet_clear_bit(DEFER_CONNECT, sk);
+	tp->fastopen_client_fail = 0;

This is an automated interdiff check for backported commits.

@github-actions
Copy link
Copy Markdown

github-actions Bot commented Jun 1, 2026

JIRA PR Check Results

6 commit(s) with issues found:

Commit ffa79e2fa2d2

Summary: tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().

❌ Errors:

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

⚠️ Warnings:

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

Commit 5a66cafa7176

Summary: sctp: linearize cloned gso packets in sctp_rcv

❌ Errors:

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

⚠️ Warnings:

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

Commit c0bf37d3bf9b

Summary: i40e: validate ring_len parameter against hardware-specific values

❌ Errors:

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

Commit 7c06892f90fd

Summary: i40e: add validation for ring_len param

❌ Errors:

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

Commit c65b682db6a1

Summary: i40e: increase max descriptors for XL710

❌ Errors:

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

Commit a568d80ab0d3

Summary: i40e: fix idx validation in config queues msg

❌ Errors:

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

⚠️ Warnings:

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

Summary: Checked 6 commit(s) total.

@github-actions
Copy link
Copy Markdown

github-actions Bot commented Jun 1, 2026

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

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