CVE-2026-90417: RDMA/cxgb4: Fix dereg_skb leak and double free in write_tpt_entry()

Published Sep 17, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

RDMA/cxgb4: Fix deregskb leak and double free in writetptentry()

When the device is in the fatal error state, writetptentry() returns -EIO before handing the caller's preallocated skb to the transmit path; its allocation-failure returns do the same. c4iwderegmr() ignores the error and frees mhp, leaking mhp->deregskb. c4iwgetdmamr() instead frees the skb a second time after deregmem() already consumed it, a double free.

Make writetptentry() the sole owner of a non-NULL skb, freeing it on every return preceding handoff to c4iwofldsend(): fatal error, tpt and stag allocation failure. c4iwofldsend() consumes the skb on success and error alike, so drop the redundant kfreeskb() in c4iwgetdmamr() after deregmem().

Affected Software

1 affected component
Linux Kernel

Event History

Sep 17, 2026
CVE Published
via MITRE·04:09 PM
Data Sourced
via MITRE·04:09 PM
Description

Frequently Asked Questions

1

What conditions trigger the memory-management errors?

The errors occur when write_tpt_entry() returns before handing a caller-provided skb to c4iw_ofld_send(), including when the device is in a fatal error state or when TPT or STAG allocation fails.

2

Which paths are affected by each issue?

c4iw_dereg_mr() can leak mhp->dereg_skb because it ignores the error from write_tpt_entry() and frees mhp. c4iw_get_dma_mr() can double-free the skb after dereg_mem() has already consumed it.

3

What is the relevant mitigation in the resolved change?

Ensure write_tpt_entry() frees any non-NULL skb on every return before transmission handoff, and remove the redundant kfree_skb() in c4iw_get_dma_mr() after dereg_mem().

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203