CVE-2026-53262 Affecting linux-qemu-melange package, versions <6.18.38-r0


Severity

Recommended
low

Based on default assessment until relevant scores are available.

Threat Intelligence

EPSS
0.13% (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 IDSNYK-CHAINGUARDLATEST-LINUXQEMUMELANGE-17949928
  • published11 Jul 2026
  • disclosed25 Jun 2026

Introduced: 25 Jun 2026

NewCVE-2026-53262  (opens in a new tab)

How to fix?

Upgrade Chainguard linux-qemu-melange to version 6.18.38-r0 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream linux-qemu-melange package and not the linux-qemu-melange package as distributed by Chainguard. See How to fix? for Chainguard relevant fixed versions and status.

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

l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()

pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF).

Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference.

To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).

CVSS Base Scores

version 3.1