CVE-2024-56633: tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg

Published Dec 27, 2024
·
Updated

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

tcpbpf: Fix the skmemuncharge logic in tcpbpfsendmsg

The current sk memory accounting logic in SKREDIRECT is pre-uncharging tosend bytes, which is either msg->sg.size or a smaller value applybytes.

Potential problems with this strategy are as follows:

- If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean.

- When tosend is set to applybytes, as in line 417, and (ret < 0), we may miss uncharging (msg->sg.size - applybytes) bytes.

[...] 415 tosend = msg->sg.size; 416 if (psock->applybytes && psock->applybytes < tosend) 417 tosend = psock->applybytes; [...] 443 skmsgreturn(sk, msg, tosend); 444 releasesock(sk); 446 origsize = msg->sg.size; 447 ret = tcpbpfsendmsgredir(skredir, rediringress, 448 msg, tosend, flags); 449 sent = origsize - msg->sg.size; [...] 454 locksock(sk); 455 if (unlikely(ret < 0)) { 456 int free = skmsgfreenocharge(sk, msg); 458 if (!cork) 459 copied -= free; 460 } [...] 487 if (eval == SKREDIRECT) 488 skmemcharge(sk, tosend - sent); [...]

When running the selftest testtxmsgredirwaitsndmem with txmsgapply, the following warning will be reported:

------------[ cut here ]------------ WARNING: CPU: 6 PID: 57 at net/ipv4/afinet.c:156 inetsockdestruct+0x190/0x1a0 Modules linked in: CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: events skpsockdestroy RIP: 0010:inetsockdestruct+0x190/0x1a0 RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206 RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800 RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900 RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0 R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400 R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100 FS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? warn+0x89/0x130 ? inetsockdestruct+0x190/0x1a0 ? reportbug+0xfc/0x1e0 ? handlebug+0x5c/0xa0 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? inetsockdestruct+0x190/0x1a0 skdestruct+0x25/0x220 skpsockdestroy+0x2b2/0x310 processscheduledworks+0xa3/0x3e0 workerthread+0x117/0x240 ? pfxworkerthread+0x10/0x10 kthread+0xcf/0x100 ? pfxkthread+0x10/0x10 retfromfork+0x31/0x40 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]---

In SKREDIRECT, a more concise way is delaying the uncharging after sent bytes are finalized, and uncharge this value. When (ret < 0), we shall invoke skmsgfree.

Same thing happens in case SKDROP, when tosend is set to applybytes, we may miss uncharging (msg->sg.size - applybytes) bytes. The same warning will be reported in selftest.

[...] 468 case SKDROP: 469 default: 470 skmsgfreepartial(sk, msg, tosend); 471 skmsgapplybytes(psock, tosend); 472 copied -= (tosend + delta); 473 return -EACCES; [...]

So instead of skmsgfreepartial we can do skmsgfree here.

Other sources

This CVE was automatically created from a reference found in an email or other text. If you are reading this, then this CVE entry is probably erroneous, since this text should be replaced by the official CVE description automatically.

Launchpad

Affected Software

10 affected componentsFixes available
Linux Kernel
debian/linux<=5.10.223-1
5.10.234-16.1.129-16.1.135-16.12.27-1
debian/linux-6.1
6.1.129-1~deb11u1
Linux Linux kernel>=4.20<5.4.287
Linux Linux kernel>=5.5<5.10.231
Linux Linux kernel>=5.11<5.15.174
Linux Linux kernel>=5.16<6.1.120
Linux Linux kernel>=6.2<6.6.66
Linux Linux kernel>=6.7<6.12.5
Linux Linux kernel=6.13-rc1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade debian/linux to a version that resolves this vulnerability.

    Fixed in 5.10.234-1Fixed in 6.1.129-1Fixed in 6.1.135-1Fixed in 6.12.27-1
  2. Upgrade

    Upgrade debian/linux-6.1 to a version that resolves this vulnerability.

    Fixed in 6.1.129-1~deb11u1
  3. Upgrade

    Upgrade linux kernel tcp_bpf to a version that resolves this vulnerability.

    Fixed in 6.12.0-rc1.bm.1-amd64+ #43Patch tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg
  4. Upgrade

    Upgrade linux kernel net/ipv4/af_inet.c:156 inet_sock_destruct to a version that resolves this vulnerability.

    Fixed in 6.12.0-rc1.bm.1-amd64+ #43Patch tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg

Event History

Dec 27, 2024
CVE Published
via MITRE·03:02 PM
Data Sourced
via MITRE·03:02 PM
Description
Data Sourced
via NVD·03:15 PM
Description
Data Sourced
via NVD·03:15 PM
RemedySeverityAffected Software
Data Sourced
via Red Hat·04:02 PM
DescriptionSeverityAffected Software
Mar 31, 2025
Data Sourced
via Launchpad·06:46 PM
Description
May 2, 2025
Data Sourced
via Ubuntu·06:54 PM
RemedyDescriptionSeverityAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2024-56633?

CVE-2024-56633 has not been assigned a severity rating yet as it is recent.

2

How do I fix CVE-2024-56633?

To mitigate CVE-2024-56633, update to a patched version of the Linux kernel, such as version 6.12.0 or later.

3

What does CVE-2024-56633 affect?

CVE-2024-56633 affects the Linux kernel, specifically the tcp_bpf functionality.

4

What is the impact of CVE-2024-56633?

CVE-2024-56633 can potentially lead to improper memory accounting in the kernel.

5

Is CVE-2024-56633 publicly known?

Yes, CVE-2024-56633 is a publicly known vulnerability affecting the Linux kernel.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203