# CVE-2024-47659: smack: tcp: ipv4, fix incorrect labeling

> Smack MAC bypass allows unauthorized writes via incorrect TCP packet labeling, requiring Smack to be enabled.

- **Severity:** Critical 9.1 (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 9 Oct 2024
- **Updated:** 5 Aug 2026
- **Also known as:** BELL-CVE-2024-47659, DEBIAN-CVE-2024-47659, GHSA-753j-68h2-88xf, ROOT-OS-DEBIAN-11-CVE-2024-47659, UBUNTU-CVE-2024-47659

## What is CVE-2024-47659?

CVE-2024-47659 is a critical vulnerability in Linux kernel, published on 9 Oct 2024. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official 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.

## Which versions are affected by CVE-2024-47659?

It affects 1 product.


Products: Linux kernel.

## How do I fix CVE-2024-47659?

Apply the vendor's patch.

## Is CVE-2024-47659 being exploited?

There is no known exploitation of CVE-2024-47659 in the wild and no public exploit code.

## Other vulnerabilities in Linux kernel

- [CVE-2026-53266](https://insights.sbomify.com/CVE-2026-53266/): Linux Kernel Out-of-Bounds Write (high 8.8, exploited in the wild)
- [CVE-2013-6282](https://insights.sbomify.com/CVE-2013-6282/): Linux Kernel Improper Input Validation (high 8.8, exploited in the wild)
- [CVE-2022-0185](https://insights.sbomify.com/CVE-2022-0185/): Linux Kernel Heap-Based Buffer Overflow (high 8.4, exploited in the wild)
- [CVE-2013-2094](https://insights.sbomify.com/CVE-2013-2094/): Linux Kernel Privilege Escalation (high 8.4, exploited in the wild)
- [CVE-2026-53362](https://insights.sbomify.com/CVE-2026-53362/): Linux Kernel Unspecified (high 7.8, exploited in the wild)

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2024-47659 and fix it if it is affected.

What it is: CVE-2024-47659 is a critical vulnerability in Linux kernel, published on 9 Oct 2024. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2024-47659 in the wild and no public exploit code.

Affected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2024-47659/ (Markdown: https://insights.sbomify.com/CVE-2024-47659/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2024-47659
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2024-47659
- OSV: https://osv.dev/vulnerability/CVE-2024-47659

---
From sbomify Insights: https://insights.sbomify.com/CVE-2024-47659/
Summaries are generated and may contain mistakes; the official description above is the record.