CVE-2025-38349

Technical Description

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

eventpoll: don't decrement ep refcount while still holding the ep mutex

Jann Horn points out that epoll is decrementing the ep refcount and then

doing a

mutex_unlock(&ep->mtx);

afterwards. That's very wrong, because it can lead to a use-after-free.

That pattern is actually fine for the very last reference, because the

code in question will delay the actual call to "ep_free(ep)" until after

it has unlocked the mutex.

But it's wrong for the much subtler "next to last" case when somebody

*else* may also be dropping their reference and free the ep while we're

still using the mutex.

Note that this is true even if that other user is also using the same ep

mutex: mutexes, unlike spinlocks, can not be used for object ownership,

even if they guarantee mutual exclusion.

A mutex "unlock" operation is not atomic, and as one user is still

accessing the mutex as part of unlocking it, another user can come in

and get the

Remediation

Check the references section for vendor advisories and patches from linux. Update linux_kernel to the latest patched version. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

Affected Products

References