linux-kernel - "Bug in qdisc_create" in Linux kernel version 2.6.26

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKHoSAtJSK6tYjZ8djK27LVuPvAVC=r+Hziv2oxA7vAYZw+30w@mail.gmail.com>
Date: Mon, 2 Dec 2024 12:31:00 +0800
From: cheung wall <zzqq0103.hey@...il.com>
To: hadi@...erus.ca, "David S. Miller" <davem@...emloft.net>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: "Bug in qdisc_create" in Linux kernel version 2.6.26

Hello,

I am writing to report a potential vulnerability identified in the
Linux Kernel version 2.6.26.
This issue was discovered using our custom vulnerability discovery
tool.

Affected File:

File: net/sched/sch_dsmark.c
Function: qdisc_create

Detailed call trace:

[ 2020.553610] Pid: 23156, comm: a.out Tainted: G D 2.6.26-1-amd64 #1
[ 2020.553610] RIP: 0010:[<ffffffffa030b3a0>] [<ffffffffa030b3a0>]
:sch_dsmark:dsmark_init+0x45/0x123
[ 2020.553610] RSP: 0018:ffff8101711a39a8 EFLAGS: 00000246
[ 2020.553610] RAX: 0000000000000000 RBX: ffff810238109a00 RCX: 0000000000000008
[ 2020.553610] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffff810238109634
[ 2020.553610] RBP: 0000000000010000 R08: ffffffffa030b8c0 R09: ffff810238109624
[ 2020.553610] R10: ffff81000109f8f0 R11: 0000000000200200 R12: 0000000080020000
[ 2020.553610] R13: ffff810238109a00 R14: ffff810238109600 R15: ffffffffa030c300
[ 2020.553610] FS: 00007f375936f6e0(0000) GS:ffff81023beefc40(0000)
knlGS:0000000000000000
[ 2020.553610] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 2020.553610] CR2: 0000000000000004 CR3: 0000000156c8f000 CR4: 00000000000006e0
[ 2020.553610] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2020.553610] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 2020.553610] Process a.out (pid: 23156, threadinfo ffff8101711a2000,
task ffff81022d116fa0)
[ 2020.553610] Stack: 0000000000000000 0000000000000000
ffff810238109634 0000000000000000
[ 2020.553610] 0000000000000000 0000000000000000 ffff810238109a00
0000000000010000
[ 2020.553610] 0000000080020000 ffff81023b1db000 ffff810238109600
ffffffff803ccf98
[ 2020.553610] Call Trace:
[ 2020.553610] [<ffffffff803ccf98>] ? qdisc_create+0x166/0x21e
[ 2020.553610] [<ffffffff803cdb33>] ? tc_modify_qdisc+0x286/0x393
[ 2020.553690] [<ffffffff803c3bf3>] ? rtnetlink_rcv_msg+0x0/0x1dd
[ 2020.553690] [<ffffffff803d1cc8>] ? netlink_rcv_skb+0x34/0x7c
[ 2020.553690] [<ffffffff803c3bed>] ? rtnetlink_rcv+0x18/0x1e
[ 2020.553690] [<ffffffff803d1ab3>] ? netlink_unicast+0x1e9/0x261
[ 2020.553690] [<ffffffff803b5f34>] ? __alloc_skb+0x7f/0x12d
[ 2020.553690] [<ffffffff803d2280>] ? netlink_sendmsg+0x274/0x287
[ 2020.553690] [<ffffffffa0113e46>] ?
:ext3:__ext3_journal_dirty_metadata+0x1e/0x46
[ 2020.553690] [<ffffffff803afea1>] ? sock_sendmsg+0xe2/0xff
[ 2020.553690] [<ffffffff802461a9>] ? autoremove_wake_function+0x0/0x2e
[ 2020.553690] [<ffffffff8027ca79>] ? zone_statistics+0x3a/0x8e
[ 2020.553690] [<ffffffff80276423>] ? get_page_from_freelist+0x45a/0x603
[ 2020.553690] [<ffffffff8027117a>] ? find_lock_page+0x1f/0x8a
[ 2020.553690] [<ffffffff8027e7c7>] ? __do_fault+0x39b/0x3e6
[ 2020.553690] [<ffffffff803b00d5>] ? sys_sendmsg+0x217/0x28a
[ 2020.553690] [<ffffffff803b1f69>] ? lock_sock_nested+0x9b/0xa6
[ 2020.553690] [<ffffffff802817df>] ? handle_mm_fault+0x3f4/0x867
[ 2020.553690] [<ffffffff80429e2d>] ? _spin_lock_bh+0x9/0x1f
[ 2020.553690] [<ffffffff803b1e4b>] ? release_sock+0x13/0x96
[ 2020.553690] [<ffffffff803b0aea>] ? move_addr_to_user+0x5d/0x78
[ 2020.553690] [<ffffffff803b0f9c>] ? sys_getsockname+0x7a/0xaa
[ 2020.553690] [<ffffffff8020beca>] ? system_call_after_swapgs+0x8a/0x8f
[ 2020.553690]
[ 2020.553690]
[ 2020.553690] Code: 0e 48 8d 56 04 48 89 e7 49 c7 c0 c0 b8 30 a0 be
05 00 00 00 83 e9 04 e8 dc 7f 0c e0 85 c0 89 c2 0f 88 d4 00 00 00 48
8b 44 24 08 <66> 8b 68 04 0f b7 fd e8 f8 7b 01 e0 ff c8 0f 85 b6 00 00
00 48
[ 2020.553690] RIP [<ffffffffa030b3a0>] :sch_dsmark:dsmark_init+0x45/0x123
[ 2020.553691] RSP <ffff8101711a39a8>
[ 2020.553691] CR2: 0000000000000004
[ 2020.558108] ---[ end trace 9deab910d1f789fc ]---

Repro C Source Code: https://pastebin.com/Gmj8kvJB

Root Cause:

The root cause of this bug lies in the dsmark_init function within the
sch_dsmark module, where an invalid memory access occurs due to a null
pointer dereference (CR2: 0000000000000004). The PoC triggers this
issue by invoking a series of socket-related system calls, including
socket, bind, getsockname, and sendmsg, with crafted parameters and
malformed data. This results in the improper initialization or
handling of the dsmark traffic control queueing discipline, leading to
an assertion failure and kernel crash. The issue arises from
insufficient input validation and error handling during the
initialization of the sch_dsmark structure, where certain fields are
not properly set up before being accessed, violating kernel invariants
and causing the crash.

Thank you for your time and attention.

Best regards

Wall