Homepage

NULL Pointer Dereference Affecting bpftool package, versions <0:5.15.0-318.199.3.2.el8uek

Severity

 Recommended
high

Based on Oracle Linux security rating.

Threat Intelligence

EPSS
0.01% (3rd percentile)

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 applications

Snyk Learn

Learn about NULL Pointer Dereference vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-ORACLE8-BPFTOOL-15566658
  • published15 Mar 2026
  • disclosed14 Feb 2026
Report a new vulnerability Found a mistake?

Introduced: 14 Feb 2026

CVE-2026-23125  (opens in a new tab)
CWE-476  (opens in a new tab)

How to fix?

Upgrade Oracle:8 bpftool to version 0:5.15.0-318.199.3.2.el8uek or higher.
This issue was patched in ELSA-2026-50145.

NVD Description

Note: Versions mentioned in the description apply only to the upstream bpftool package and not the bpftool package as distributed by Oracle. See How to fix? for Oracle:8 relevant fixed versions and status.

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

sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT

A null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key initialization fails:

================================================================== KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2 RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline] RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401 Call Trace:

sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189 sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111 sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217 sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052 sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88 sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243 sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127

The issue is triggered when sctp_auth_asoc_init_active_key() fails in sctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the command sequence is currently:

  • SCTP_CMD_PEER_INIT
  • SCTP_CMD_TIMER_STOP (T1_INIT)
  • SCTP_CMD_TIMER_START (T1_COOKIE)
  • SCTP_CMD_NEW_STATE (COOKIE_ECHOED)
  • SCTP_CMD_ASSOC_SHKEY
  • SCTP_CMD_GEN_COOKIE_ECHO

If SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, while asoc->peer.auth_capable and asoc->peer.peer_chunks have already been set by SCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL to be queued by sctp_datamsg_from_user().

Since command interpretation stops on failure, no COOKIE_ECHO should been sent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already been started, and it may enqueue a COOKIE_ECHO into the outqueue later. As a result, the DATA chunk can be transmitted together with the COOKIE_ECHO in sctp_outq_flush_data(), leading to the observed issue.

Similar to the other places where it calls sctp_auth_asoc_init_active_key() right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY immediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting T1_COOKIE. This ensures that if shared key generation fails, authenticated DATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT, giving the client another chance to process INIT_ACK and retry key setup.

CVSS Base Scores

version 3.1