Use After Free Affecting kernel-livepatch-5_14_21-150400_24_161-default package, versions <1-150400.9.3.1


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.02% (4th 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 Use After Free vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-SLES154-KERNELLIVEPATCH5142115040024161DEFAULT-9686394
  • published11 Apr 2025
  • disclosed10 Apr 2025

Introduced: 10 Apr 2025

NewCVE-2023-53016  (opens in a new tab)
CWE-416  (opens in a new tab)
CWE-667  (opens in a new tab)

How to fix?

Upgrade SLES:15.4 kernel-livepatch-5_14_21-150400_24_161-default to version 1-150400.9.3.1 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-livepatch-5_14_21-150400_24_161-default package and not the kernel-livepatch-5_14_21-150400_24_161-default package as distributed by SLES. See How to fix? for SLES:15.4 relevant fixed versions and status.

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

Bluetooth: Fix possible deadlock in rfcomm_sk_state_change

syzbot reports a possible deadlock in rfcomm_sk_state_change [1]. While rfcomm_sock_connect acquires the sk lock and waits for the rfcomm lock, rfcomm_sock_release could have the rfcomm lock and hit a deadlock for acquiring the sk lock. Here's a simplified flow:

rfcomm_sock_connect: lock_sock(sk) rfcomm_dlc_open: rfcomm_lock()

rfcomm_sock_release: rfcomm_sock_shutdown: rfcomm_lock() __rfcomm_dlc_close: rfcomm_k_state_change: lock_sock(sk)

This patch drops the sk lock before calling rfcomm_dlc_open to avoid the possible deadlock and holds sk's reference count to prevent use-after-free after rfcomm_dlc_open completes.

CVSS Base Scores

version 3.1