Bug 2532370 (CVE-2026-80982) - CVE-2026-80982 kernel: net/smc: fix use-after-free in smc_rx_pipe_buf_release()
Summary: CVE-2026-80982 kernel: net/smc: fix use-after-free in smc_rx_pipe_buf_release()
Keywords:
Status: NEW
Alias: CVE-2026-80982
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-09-11 22:36 UTC by OSIDB Bzimport
Modified: 2026-09-14 19:08 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-09-11 22:36:14 UTC
In the Linux kernel, the following vulnerability has been resolved:

net/smc: fix use-after-free in smc_rx_pipe_buf_release()

smc_rx_splice() hands RMB pages to a pipe and takes a socket reference
per entry so the smc_sock stays alive until the reader finishes. The
connection does not: a concurrent close runs smc_conn_free(), which
releases the receive buffer back to the link group pool.

smc_rx_pipe_buf_release() tests sk_state before taking the socket lock.
The state can change between the test and the lock, and
smc_rx_update_cons() then dereferences conn->rmb_desc and walks
conn->lgr, which smc_conn_free() has already released. On the
is_reg_err path smcr_buf_unuse() frees the descriptor outright, so
this is a use-after-free.

Take the socket lock first and test conn->freed instead.
smc_conn_free() sets that flag before releasing anything, and every
caller holds the socket lock. The two paths exclude each other: either
the pipe release runs first with everything valid, or it sees the flag
and skips the update.


Note You need to log in before you can comment on or make changes to this bug.