NULL Pointer Dereference Affecting kernel-debug package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsSnyk Learn
Learn about NULL Pointer Dereference vulnerabilities in an interactive lesson.
Start learning- Snyk IDSNYK-CENTOS6-KERNELDEBUG-16076848
- published16 Apr 2026
- disclosed13 Apr 2026
Introduced: 13 Apr 2026
NewCVE-2026-31425 (opens in a new tab)How to fix?
There is no fixed version for Centos:6 kernel-debug.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-debug package and not the kernel-debug package as distributed by Centos.
See How to fix? for Centos:6 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
rds: ib: reject FRMR registration before IB connection is established
rds_ib_get_mr() extracts the rds_ib_connection from conn->c_transport_data and passes it to rds_ib_reg_frmr() for FRWR memory registration. On a fresh outgoing connection, ic is allocated in rds_ib_conn_alloc() with i_cm_id = NULL because the connection worker has not yet called rds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() with RDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parses the control message before any connection establishment, allowing rds_ib_post_reg_frmr() to dereference ic->i_cm_id->qp and crash the kernel.
The existing guard in rds_ib_reg_frmr() only checks for !ic (added in commit 9e630bcb7701), which does not catch this case since ic is allocated early and is always non-NULL once the connection object exists.
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920 Call Trace: rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167) rds_ib_map_frmr (net/rds/ib_frmr.c:252) rds_ib_reg_frmr (net/rds/ib_frmr.c:430) rds_ib_get_mr (net/rds/ib_rdma.c:615) __rds_rdma_map (net/rds/rdma.c:295) rds_cmsg_rdma_map (net/rds/rdma.c:860) rds_sendmsg (net/rds/send.c:1363) ____sys_sendmsg do_syscall_64
Add a check in rds_ib_get_mr() that verifies ic, i_cm_id, and qp are all non-NULL before proceeding with FRMR registration, mirroring the guard already present in rds_ib_post_inv(). Return -ENODEV when the connection is not ready, which the existing error handling in rds_cmsg_send() converts to -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() to start the connection worker.
References
- https://access.redhat.com/security/cve/CVE-2026-31425
- https://git.kernel.org/stable/c/23e07c340c445f0ebff7757ba15434cb447eb662
- https://git.kernel.org/stable/c/450ec93c0f172374acbf236f1f5f02d53650aa2d
- https://git.kernel.org/stable/c/47de5b73db3b88f45c107393f26aeba26e9e8fae
- https://git.kernel.org/stable/c/6b0a8de67ac0c74e1a7df92b73c862cb36780dfc
- https://git.kernel.org/stable/c/a54ecccfae62c5c85259ae5ea5d9c20009519049
- https://git.kernel.org/stable/c/a5bfd14c9a299e6db4add4440430ee5e010b03ad
- https://git.kernel.org/stable/c/82e4a3b56b23b844802056c9e75a39d24169b0a4
- https://git.kernel.org/stable/c/c506456ebf84c50ed9327473d4e9bd905def212b