Bug 1223720 (CVE-2024-27010) - VUL-0: CVE-2024-27010: kernel: net/sched: Fix mirred deadlock on device recursion
Summary: VUL-0: CVE-2024-27010: kernel: net/sched: Fix mirred deadlock on device recur...
Status: NEW
Alias: CVE-2024-27010
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Denis Kirjanov
QA Contact: Security Team bot
URL: https://smash.suse.de/issue/403778/
Whiteboard: CVSSv3.1:SUSE:CVE-2024-27010:5.5:(AV:...
Keywords:
Depends on:
Blocks:
 
Reported: 2024-05-02 11:51 UTC by SMASH SMASH
Modified: 2024-05-03 14:38 UTC (History)
2 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description SMASH SMASH 2024-05-02 11:51:38 UTC
In the Linux kernel, the following vulnerability has been resolved:

net/sched: Fix mirred deadlock on device recursion

When the mirred action is used on a classful egress qdisc and a packet is
mirrored or redirected to self we hit a qdisc lock deadlock.
See trace below.

[..... other info removed for brevity....]
[   82.890906]
[   82.890906] ============================================
[   82.890906] WARNING: possible recursive locking detected
[   82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G        W
[   82.890906] --------------------------------------------
[   82.890906] ping/418 is trying to acquire lock:
[   82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:
__dev_queue_xmit+0x1778/0x3550
[   82.890906]
[   82.890906] but task is already holding lock:
[   82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:
__dev_queue_xmit+0x1778/0x3550
[   82.890906]
[   82.890906] other info that might help us debug this:
[   82.890906]  Possible unsafe locking scenario:
[   82.890906]
[   82.890906]        CPU0
[   82.890906]        ----
[   82.890906]   lock(&sch->q.lock);
[   82.890906]   lock(&sch->q.lock);
[   82.890906]
[   82.890906]  *** DEADLOCK ***
[   82.890906]
[..... other info removed for brevity....]

Example setup (eth0->eth0) to recreate
tc qdisc add dev eth0 root handle 1: htb default 30
tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \
     action mirred egress redirect dev eth0

Another example(eth0->eth1->eth0) to recreate
tc qdisc add dev eth0 root handle 1: htb default 30
tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \
     action mirred egress redirect dev eth1

tc qdisc add dev eth1 root handle 1: htb default 30
tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \
     action mirred egress redirect dev eth0

We fix this by adding an owner field (CPU id) to struct Qdisc set after
root qdisc is entered. When the softirq enters it a second time, if the
qdisc owner is the same CPU, the packet is dropped to break the loop.

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-27010
https://www.cve.org/CVERecord?id=CVE-2024-27010
https://git.kernel.org/stable/c/0f022d32c3eca477fbf79a205243a6123ed0fe11
https://git.kernel.org/stable/c/e6b90468da4dae2281a6e381107f411efb48b0ef
https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-27010.mbox
https://bugzilla.redhat.com/show_bug.cgi?id=2278279