Homepage

NULL Pointer Dereference The advisory has been revoked - it doesn't affect any version of package kernel-zfcpdump-modules-internal  (opens in a new tab)

Threat Intelligence

EPSS
0.2% (11th 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 IDSNYK-RHEL9-KERNELZFCPDUMPMODULESINTERNAL-9124486
  • published5 Mar 2025
  • disclosed27 Feb 2025
Report a new vulnerability Found a mistake?

Introduced: 27 Feb 2025

CVE-2024-58009  (opens in a new tab)
CWE-476  (opens in a new tab)

Amendment

The Red Hat security team deemed this advisory irrelevant for RHEL:9.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-zfcpdump-modules-internal package and not the kernel-zfcpdump-modules-internal package as distributed by RHEL.

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

Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_alloc

A NULL sock pointer is passed into l2cap_sock_alloc() when it is called from l2cap_sock_new_connection_cb() and the error handling paths should also be aware of it.

Seemingly a more elegant solution would be to swap bt_sock_alloc() and l2cap_chan_create() calls since they are not interdependent to that moment but then l2cap_chan_create() adds the soon to be deallocated and still dummy-initialized channel to the global list accessible by many L2CAP paths. The channel would be removed from the list in short period of time but be a bit more straight-forward here and just check for NULL instead of changing the order of function calls.

Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool.