CVE-2025-21864 - NULL Pointer Dereference

Severity

55%

Complexity

18%

Confidentiality

60%

In the Linux kernel, the following vulnerability has been resolved: tcp: drop secpath at the same time as we currently drop dst Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while running tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netns The xfrm_state found on spi_byaddr was not deleted at the time we delete the netns, because we still have a reference on it. This lingering reference comes from a secpath (which holds a ref on the xfrm_state), which is still attached to an skb. This skb is not leaked, it ends up on sk_receive_queue and then gets defer-free'd by skb_attempt_defer_free. The problem happens when we defer freeing an skb (push it on one CPU's defer_list), and don't flush that list before the netns is deleted. In that case, we still have a reference on the xfrm_state that we don't expect at this point. We already drop the skb's dst in the TCP receive path when it's no longer needed, so let's also drop the secpath. At this point, tcp_filter has already called into the LSM hooks that may require the secpath, so it should not be needed anymore. However, in some of those places, the MPTCP extension has just been attached to the skb, so we cannot simply drop all extensions.

CVSS 3.1 Base Score 5.5. CVSS Attack Vector: local. CVSS Attack Complexity: low. CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).

Demo Examples

NULL Pointer Dereference

CWE-476

While there are no complete fixes aside from conscientious programming, the following steps will go a long way to ensure that NULL pointer dereferences do not occur.


               
}
/* make use of pointer1 *//* ... */

If you are working with a multithreaded or otherwise asynchronous environment, ensure that proper locking APIs are used to lock before the if statement; and unlock when it has finished.

NULL Pointer Dereference

CWE-476

This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.


               
}
strcpy(hostname, hp->h_name);/*routine that ensures user_supplied_addr is in the right format for conversion */

If an attacker provides an address that appears to be well-formed, but the address does not resolve to a hostname, then the call to gethostbyaddr() will return NULL. Since the code does not check the return value from gethostbyaddr (CWE-252), a NULL pointer dereference would then occur in the call to strcpy().

Note that this example is also vulnerable to a buffer overflow (see CWE-119).

NULL Pointer Dereference

CWE-476

In the following code, the programmer assumes that the system always has a property named "cmd" defined. If an attacker can control the program's environment so that "cmd" is not defined, the program throws a NULL pointer exception when it attempts to call the trim() method.


               
cmd = cmd.trim();

NULL Pointer Dereference

CWE-476

This application has registered to handle a URL when sent an intent:


               
}......
}
}
int length = URL.length();
...

The application assumes the URL will always be included in the intent. When the URL is not present, the call to getStringExtra() will return null, thus causing a null pointer exception when length() is called.

Stay updated

ExploitPedia is constantly evolving. Sign up to receive a notification when we release additional functionality.

Get in touch

If you'd like to report a bug or have any suggestions for improvements then please do get in touch with us using this form. We will get back to you as soon as we can.