Cloudanix VulnDB

CVE-2023-54112

None

CVSS

—

EPSS

0.2%

Published

Dec 24, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A coding mistake in network message handling can slowly consume system memory when certain errors occur, eventually making the application or server slow or unresponsive.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Memory leak in kcm_sendmsg() error path where partial skb allocation leaves last_skb unmodified, corrupting head frag_list and leaving sk_buff objects unreferenced.

Why it matters to the business

Repeated triggering leads to gradual memory exhaustion that can degrade performance or cause denial of service on systems running the affected software.

How an attack unfolds

An attacker invokes kcm_sendmsg with inputs that allocate skbs then hit an error after partial copy, leaving stale last_skb references that leak memory on later calls.

How to fix it

Upgrade ajnart/homarr to the fixed commit 2b3a4393f3569939a538bf7a2b8f588bb4e238be.

How to confirm the fix worked

Confirm the presence of commit 2b3a4393f3569939a538bf7a2b8f588bb4e238be in the source tree and verify absence of the original leak path in kcm_sendmsg.

Typical attack path

  1. Locate systems exposing kcm socket interfaces
  2. Craft sendmsg sequences that allocate skbs then force an error condition
  3. Repeat to accumulate unreferenced sk_buff objects
  4. Observe memory growth until resource exhaustion

How to detect it

Review kernel or application logs for memory-leak reports referencing kcm_sendmsg or unreferenced sk_buff objects; correlate with processes performing repeated sendmsg operations on kcm sockets.

What your security team should do

  • Apply the listed commit immediately on all instances
  • Audit any custom kcm socket usage for similar error-handling patterns
  • Monitor memory usage trends on affected hosts

The record

In the Linux kernel, the following vulnerability has been resolved: kcm: Fix memory leak in error path of kcm_sendmsg() syzbot reported a memory leak like below: BUG: memory leak unreferenced object 0xffff88810b088c00 (size 240): comm "syz-executor186", pid 5012, jiffies 4294943306 (age 13.680s) hex dump (first 32 bytes): 00 89 08 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff83e5d5ff>] __alloc_skb+0x1ef/0x230 net/core/skbuff.c:634 [<ffffffff84606e59>] alloc_skb include/linux/skbuff.h:1289 [inline] [<ffffffff84606e59>] kcm_sendmsg+0x269/0x1050 net/kcm/kcmsock.c:815 [<ffffffff83e479c6>] sock_sendmsg_nosec net/socket.c:725 [inline] [<ffffffff83e479c6>] sock_sendmsg+0x56/0xb0 net/socket.c:748 [<ffffffff83e47f55>] ____sys_sendmsg+0x365/0x470 net/socket.c:2494 [<ffffffff83e4c389>] ___sys_sendmsg+0xc9/0x130 net/socket.c:2548 [<ffffffff83e4c536>] __sys_sendmsg+0xa6/0x120 net/socket.c:2577 [<ffffffff84ad7bb8>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84ad7bb8>] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 [<ffffffff84c0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd In kcm_sendmsg(), kcm_tx_msg(head)->last_skb is used as a cursor to append newly allocated skbs to 'head'. If some bytes are copied, an error occurred, and jumped to out_error label, 'last_skb' is left unmodified. A later kcm_sendmsg() will use an obsoleted 'last_skb' reference, corrupting the 'head' frag_list and causing the leak. This patch fixes this issue by properly updating the last allocated skb in 'last_skb'.

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 4.6.0 4.14.326
SUSE:Linux Enterprise High Availability Extension 15 SP6 kernel-default 0 6.4.0-150600.23.84.1
SUSE:Linux Enterprise Live Patching 15 SP6 kernel-default 0 6.4.0-150600.23.84.1
SUSE:Linux Enterprise Live Patching 15 SP6 kernel-livepatch-SLE15-SP6_Update_19 0 1-150600.13.3.1
SUSE:Linux Enterprise Server 15 SP6-LTSS kernel-64kb 0 6.4.0-150600.23.84.1
SUSE:Linux Enterprise Server 15 SP6-LTSS kernel-default 0 6.4.0-150600.23.84.1
SUSE:Linux Enterprise Server 15 SP6-LTSS kernel-default-base 0 6.4.0-150600.23.84.1.150600.12.38.1
SUSE:Linux Enterprise Server 15 SP6-LTSS kernel-docs 0 6.4.0-150600.23.84.1
SUSE:Linux Enterprise Server 15 SP6-LTSS kernel-obs-build 0 6.4.0-150600.23.84.1
SUSE:Linux Enterprise Server 15 SP6-LTSS kernel-source 0 6.4.0-150600.23.84.1
SUSE:Linux Enterprise Server 15 SP6-LTSS kernel-syms 0 6.4.0-150600.23.84.1
SUSE:Linux Enterprise Server 15 SP6-LTSS kernel-zfcpdump 0 6.4.0-150600.23.84.1
SUSE:Linux Enterprise Server for SAP Applications 15 SP6 kernel-default 0 6.4.0-150600.23.84.1
SUSE:Linux Enterprise Server for SAP Applications 15 SP6 kernel-default-base 0 6.4.0-150600.23.84.1.150600.12.38.1
SUSE:Linux Enterprise Server for SAP Applications 15 SP6 kernel-docs 0 6.4.0-150600.23.84.1
SUSE:Linux Enterprise Server for SAP Applications 15 SP6 kernel-obs-build 0 6.4.0-150600.23.84.1
SUSE:Linux Enterprise Server for SAP Applications 15 SP6 kernel-source 0 6.4.0-150600.23.84.1
SUSE:Linux Enterprise Server for SAP Applications 15 SP6 kernel-syms 0 6.4.0-150600.23.84.1
openSUSE:Leap 15.6 dtb-aarch64 0 6.4.0-150600.23.84.1
openSUSE:Leap 15.6 kernel-64kb 0 6.4.0-150600.23.84.1
openSUSE:Leap 15.6 kernel-debug 0 6.4.0-150600.23.84.1
openSUSE:Leap 15.6 kernel-default 0 6.4.0-150600.23.84.1
openSUSE:Leap 15.6 kernel-default-base 0 6.4.0-150600.23.84.1.150600.12.38.1
openSUSE:Leap 15.6 kernel-docs 0 6.4.0-150600.23.84.1
openSUSE:Leap 15.6 kernel-kvmsmall 0 6.4.0-150600.23.84.1
openSUSE:Leap 15.6 kernel-obs-build 0 6.4.0-150600.23.84.1
openSUSE:Leap 15.6 kernel-obs-qa 0 6.4.0-150600.23.84.1
openSUSE:Leap 15.6 kernel-source 0 6.4.0-150600.23.84.1
openSUSE:Leap 15.6 kernel-syms 0 6.4.0-150600.23.84.1
openSUSE:Leap 15.6 kernel-zfcpdump 0 6.4.0-150600.23.84.1

Related vulnerabilities