fkie_cve-2025-38553
Vulnerability from fkie_nvd
Published
2025-08-19 06:15
Modified
2025-08-28 15:15
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Restrict conditions for adding duplicating netems to qdisc tree
netem_enqueue's duplication prevention logic breaks when a netem
resides in a qdisc tree with other netems - this can lead to a
soft lockup and OOM loop in netem_dequeue, as seen in [1].
Ensure that a duplicating netem cannot exist in a tree with other
netems.
Previous approaches suggested in discussions in chronological order:
1) Track duplication status or ttl in the sk_buff struct. Considered
too specific a use case to extend such a struct, though this would
be a resilient fix and address other previous and potential future
DOS bugs like the one described in loopy fun [2].
2) Restrict netem_enqueue recursion depth like in act_mirred with a
per cpu variable. However, netem_dequeue can call enqueue on its
child, and the depth restriction could be bypassed if the child is a
netem.
3) Use the same approach as in 2, but add metadata in netem_skb_cb
to handle the netem_dequeue case and track a packet's involvement
in duplication. This is an overly complex approach, and Jamal
notes that the skb cb can be overwritten to circumvent this
safeguard.
4) Prevent the addition of a netem to a qdisc tree if its ancestral
path contains a netem. However, filters and actions can cause a
packet to change paths when re-enqueued to the root from netem
duplication, leading us to the current solution: prevent a
duplicating netem from inhabiting the same tree as other netems.
[1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/
[2] https://lwn.net/Articles/719297/
References
Impacted products
| Vendor | Product | Version |
|---|
{
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Restrict conditions for adding duplicating netems to qdisc tree\n\nnetem_enqueue\u0027s duplication prevention logic breaks when a netem\nresides in a qdisc tree with other netems - this can lead to a\nsoft lockup and OOM loop in netem_dequeue, as seen in [1].\nEnsure that a duplicating netem cannot exist in a tree with other\nnetems.\n\nPrevious approaches suggested in discussions in chronological order:\n\n1) Track duplication status or ttl in the sk_buff struct. Considered\ntoo specific a use case to extend such a struct, though this would\nbe a resilient fix and address other previous and potential future\nDOS bugs like the one described in loopy fun [2].\n\n2) Restrict netem_enqueue recursion depth like in act_mirred with a\nper cpu variable. However, netem_dequeue can call enqueue on its\nchild, and the depth restriction could be bypassed if the child is a\nnetem.\n\n3) Use the same approach as in 2, but add metadata in netem_skb_cb\nto handle the netem_dequeue case and track a packet\u0027s involvement\nin duplication. This is an overly complex approach, and Jamal\nnotes that the skb cb can be overwritten to circumvent this\nsafeguard.\n\n4) Prevent the addition of a netem to a qdisc tree if its ancestral\npath contains a netem. However, filters and actions can cause a\npacket to change paths when re-enqueued to the root from netem\nduplication, leading us to the current solution: prevent a\nduplicating netem from inhabiting the same tree as other netems.\n\n[1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/\n[2] https://lwn.net/Articles/719297/"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: Restringir las condiciones para agregar netems duplicados al \u00e1rbol qdisc La l\u00f3gica de prevenci\u00f3n de duplicaci\u00f3n de netem_enqueue se rompe cuando un netem reside en un \u00e1rbol qdisc con otros netems: esto puede provocar un bloqueo suave y un bucle OOM en netem_dequeue, como se ve en [1]. Aseg\u00farese de que un netem duplicado no pueda existir en un \u00e1rbol con otros netems. Enfoques previos sugeridos en discusiones en orden cronol\u00f3gico: 1) Rastrear el estado de duplicaci\u00f3n o ttl en la estructura sk_buff. Se considera un caso de uso demasiado espec\u00edfico para extender dicha estructura, aunque esta ser\u00eda una soluci\u00f3n resiliente y abordar\u00eda otros errores de DOS anteriores y futuros potenciales como el descrito en loopy fun [2]. 2) Restringir la profundidad de recursi\u00f3n de netem_enqueue como en act_mirred con una variable por CPU. Sin embargo, netem_dequeue puede ejecutar la funci\u00f3n en cola en su elemento secundario, y la restricci\u00f3n de profundidad podr\u00eda omitirse si el elemento secundario es un netem. 3) Use el mismo enfoque que en el punto 2, pero agregue metadatos en netem_skb_cb para gestionar el caso de netem_dequeue y rastrear la participaci\u00f3n de un paquete en la duplicaci\u00f3n. Este es un enfoque excesivamente complejo, y Jamal se\u00f1ala que el skb_cb puede sobrescribirse para eludir esta protecci\u00f3n. 4) Evite la adici\u00f3n de un netem a un \u00e1rbol qdisc si su ruta ancestral contiene un netem. Sin embargo, los filtros y las acciones pueden provocar que un paquete cambie de ruta al volver a encolarse a la ra\u00edz desde la duplicaci\u00f3n de netem, lo que nos lleva a la soluci\u00f3n actual: evitar que un netem duplicado ocupe el mismo \u00e1rbol que otros netems. [1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/ [2] https://lwn.net/Articles/719297/"
}
],
"id": "CVE-2025-38553",
"lastModified": "2025-08-28T15:15:52.923",
"metrics": {},
"published": "2025-08-19T06:15:33.407",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/09317dfb681ac5a96fc69bea0c54441cf91b8270"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/103c4e27ec9f5fe53022e46e976abf52c7221baf"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/250f8796006c0f2bc638ce545f601d49ae8d528b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/325f5ec67cc0a77f2d0d453445b9857f1cd06c76"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/795cb393e38977aa991e70a9363da0ee734b2114"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ad340a4b4adb855b18b3666f26ad65c8968e2deb"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/cab2809944989889f88a1a8b5cff1c78460c72cb"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ec8e0e3d7adef940cdf9475e2352c0680189d14e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/f088b6ebe8797a3f948d2cae47f34bfb45cc6522"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…