Attacker Value
Unknown
(0 users assessed)
Exploitability
Unknown
(0 users assessed)
User Interaction
None
Privileges Required
Low
Attack Vector
Local
0

CVE-2024-53140

Disclosure Date: December 04, 2024 •
CVE-2024-53140 CVSS v3 Base Score: 5.5
Add MITRE ATT&CK tactics and techniques that apply to this CVE.

Description

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

netlink: terminate outstanding dump on socket close

Netlink supports iterative dumping of data. It provides the families
the following ops:

  • start – (optional) kicks off the dumping process
  • dump – actual dump helper, keeps getting called until it returns 0
  • done – (optional) pairs with .start, can be used for cleanup
    The whole process is asynchronous and the repeated calls to .dump
    don’t actually happen in a tight loop, but rather are triggered
    in response to recvmsg() on the socket.

This gives the user full control over the dump, but also means that
the user can close the socket without getting to the end of the dump.
To make sure .start is always paired with .done we check if there
is an ongoing dump before freeing the socket, and if so call .done.

The complication is that sockets can get freed from BH and .done
is allowed to sleep. So we use a workqueue to defer the call, when
needed.

Unfortunately this does not work correctly. What we defer is not
the cleanup but rather releasing a reference on the socket.
We have no guarantee that we own the last reference, if someone
else holds the socket they may release it in BH and we’re back
to square one.

The whole dance, however, appears to be unnecessary. Only the user
can interact with dumps, so we can clean up when socket is closed.
And close always happens in process context. Some async code may
still access the socket after close, queue notification skbs to it etc.
but no dumps can start, end or otherwise make progress.

Delete the workqueue and flush the dump state directly from the release
handler. Note that further cleanup is possible in -next, for instance
we now always call .done before releasing the main module reference,
so dump doesn’t have to take a reference of its own.

Add Assessment

No one has assessed this topic. Be the first to add your voice to the community.

CVSS V3 Severity and Metrics
Base Score:
5.5 Medium
Impact Score:
3.6
Exploitability Score:
1.8
Vector:
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector (AV):
Local
Attack Complexity (AC):
Low
Privileges Required (PR):
Low
User Interaction (UI):
None
Scope (S):
Unchanged
Confidentiality (C):
None
Integrity (I):
None
Availability (A):
High

General Information

Offensive Application
Unknown
Utility Class
Unknown
Ports
Unknown
OS
Unknown
Vulnerable Versions
Linux 114a61d8d94a
Linux not down converted
Prerequisites
Unknown
Discovered By
Unknown
PoC Author
Unknown
Metasploit Module
Unknown
Reporter
Unknown

Vendors

  • linux

Products

  • linux kernel
Technical Analysis