CVE-2024-47659: linux kernel — Fix

Description

In the Linux kernel, the following vulnerability has been resolved: smack: tcp: ipv4, fix incorrect labeling Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to write. Here is a scenario how to see this: * Take two machines, let's call them C and S, with active Smack in the default state (no settings, no rules, no labeled hosts, only builtin labels) * At S, add Smack rule 'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment) * At S, at label 'bar', launch a program that listens for incoming tcp/ipv4 connections * From C, at label 'foo', connect to the listener at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works. * Send some data in both directions. * Collect network traffic of this connection. All packets in both directions are labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized, and even without ever being known at C. If anybody cares: exactly the same happens with DCCP. This behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no explanation was provided. I changed returned packes label into the 'bar', to bring it into line with the Smack documentation claims.

Is your site exposed to CVE-2024-47659?

Run a free security scan — no signup, results in seconds.

CVSS v3.1 Score

8.8

HIGH

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Affected Products

Vendor	Product	Versions
linux	linux_kernel	< 4.19.322
linux	linux_kernel	4.20 — 5.4.284
linux	linux_kernel	5.5 — 5.10.226
linux	linux_kernel	5.11 — 5.15.167
linux	linux_kernel	5.16 — 6.1.109
linux	linux_kernel	6.2 — 6.6.50
linux	linux_kernel	6.7 — 6.10.9

References

Advisories & Patches

https://git.kernel.org/stable/c/0776bcf9cb6de46fdd94d10118de1cf9b05f83b9 https://git.kernel.org/stable/c/0aea09e82eafa50a373fc8a4b84c1d4734751e2c https://git.kernel.org/stable/c/2fe209d0ad2e2729f7e22b9b31a86cc3ff0db550 https://git.kernel.org/stable/c/4be9fd15c3c88775bdf6fa37acabe6de85beebff https://git.kernel.org/stable/c/5b4b304f196c070342e32a4752e1fa2e22fc0671 https://git.kernel.org/stable/c/a948ec993541db4ef392b555c37a1186f4d61670 https://git.kernel.org/stable/c/d3703fa94116fed91f64c7d1c7d284fb4369070f https://git.kernel.org/stable/c/d3f56c653c65f170b172d3c23120bc64ada645d8

Other References

https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html

Frequently Asked Questions

What is CVE-2024-47659? +

In the Linux kernel, the following vulnerability has been resolved: smack: tcp: ipv4, fix incorrect labeling Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to write. Here is a scenario how to see this: * Take two machines, let's call them C and S, with active Smack in the default state (no settings, no rules, no labeled hosts, only builtin labels) * At S, add Smack rule 'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment) * At S, at label 'bar', launch a program that listens for incoming tcp/ipv4 connections * From C, at label 'foo', connect to the listener at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works. * Send some data in both directions. * Collect network traffic of this connection. All packets in both directions are labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized, and even without ever being known at C. If anybody cares: exactly the same happens with DCCP. This behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no explanation was provided. I changed returned packes label into the 'bar', to bring it into line with the Smack documentation claims. It has a CVSS v3.1 base score of 8.8 (HIGH).

How severe is CVE-2024-47659? +

CVE-2024-47659 has a CVSS v3.1 score of 8.8 out of 10, rated HIGH. This is a high-severity vulnerability that should be prioritized for patching.

What products are affected by CVE-2024-47659? +

CVE-2024-47659 affects products from linux, specifically: linux_kernel. Check the affected products table above for specific version ranges.

How do I check if I'm vulnerable to CVE-2024-47659? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.

Related Vulnerabilities

CVE-2026-75703 10.0

Adobe Campaign Classic (ACC) is affected by an Improper Control of Generation of Code ('Code Injection') vulnerability that could result …

CVE-2026-75721 10.0

Adobe Campaign Classic (ACC) is affected by an Improper Control of Generation of Code ('Code Injection') vulnerability that could result …

CVE-2026-75723 10.0

Adobe Campaign Classic (ACC) is affected by an Incorrect Authorization vulnerability that could result in arbitrary code execution in the …

CVE-2025-9588 10.0

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in Iron Mountain Archiving Services Inc. …

CVE-2025-57870 10.0

A SQL Injection vulnerability exists in Esri ArcGIS Server versions 11.3, 11.4 and 11.5 on Windows, Linux and Kubernetes. This …

CVE-2026-48286 10.0

Adobe Campaign Classic (ACC) versions 7.4.3 build 9396 and earlier are affected by an Incorrect Authorization vulnerability that could result …

CVE-2024-47659