Message-ID: <CAKHoSAswYPiyoc3UegpLv2yOSk2OOZuSYLPYJ47B=uvSbtF0tg@mail.gmail.com>
Date: Mon, 2 Dec 2024 12:31:06 +0800
From: cheung wall <zzqq0103.hey@...il.com>
To: linux-kernel@...r.kernel.org
Subject: "Bug in vsscanf" 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: lib/vsprintf.c
Function: vsscanf

Detailed call trace:

[ 2020.553690] RIP [<ffffffffa030b3a0>] :sch_dsmark:dsmark_init+0x45/0x123
[ 2020.553691] RSP <ffff8101711a39a8>
[ 2020.553691] CR2: 0000000000000004
[ 2020.558108] ---[ end trace 9deab910d1f789fc ]---
[ 2190.055853] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000000
[ 2190.056043] IP: [<ffffffff8031edcc>] vsscanf+0x600/0x657
[ 2190.056131] PGD 158d4c067 PUD 1691c4067 PMD 0
[ 2190.056209] Oops: 0000 [5] SMP
[ 2190.056267] CPU 16
[ 2190.056311] Modules linked in: sch_dsmark pppoe pppox l2cap
xfrm6_mode_transport crypto_null crypto_blkcipher nfnetlink_queue
dummy inet_diag fuse sch_sfq llc2 xfrm4_mode_transport tun ppp_generic
slhc xfrm_user nf_conntrack_netlink nf_nat nf_conntrack_ipv4
nf_conntrack hci_uart bluetooth nfnetlink sctp libcrc32c 9p 9pnet
xfrm4_tunnel tunnel4 ipcomp xfrm4_mode_tunnel deflate zlib_deflate
zlib_inflate af_key ipv6 loop snd_pcsp snd_pcm snd_timer serio_raw
button snd parport_pc container soundcore parport snd_page_alloc
i2c_piix4 psmouse i2c_core evdev ext3 jbd mbcache ide_cd_mod ide_disk
cdrom ata_generic libata scsi_mod dock ide_pci_generic floppy piix
e1000 ide_core thermal processor fan thermal_sys
[ 2190.059364] Pid: 23203, comm: a.out Tainted: G D 2.6.26-1-amd64 #1
[ 2190.059364] RIP: 0010:[<ffffffff8031edcc>] [<ffffffff8031edcc>]
vsscanf+0x600/0x657
[ 2190.059364] RSP: 0018:ffff8101d6039a90 EFLAGS: 00000202
[ 2190.059364] RAX: ffff8101d6039a25 RBX: 0000000000000003 RCX: ffff8101d6039bbc
[ 2190.059364] RDX: ffffffffa021a3d0 RSI: ffffffffa021a3d0 RDI: 0000000000000000
[ 2190.059364] RBP: ffff8101d6039ad8 R08: ffff8101d6039bc0 R09: ffff8101d6039bc4
[ 2190.059364] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
[ 2190.059364] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8102314a6140
[ 2190.059364] FS: 00007fcabeeea6e0(0000) GS:ffff81023b4469c0(0000)
knlGS:0000000000000000
[ 2190.059364] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 2190.059364] CR2: 0000000000000000 CR3: 0000000171938000 CR4: 00000000000006e0
[ 2190.059364] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2190.059364] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 2190.059364] Process a.out (pid: 23203, threadinfo ffff8101d6038000,
task ffff8102383a5830)
[ 2190.059364] Stack: ffffffffa021a3d0 0000000000000020
00000000001280d2 0000000000000003
[ 2190.059364] 0000000000000000 00000000ffffff01 ffff8101d6039c38
0000000000002000
[ 2190.059364] ffffffff8031ee6c 0000003000000010 ffff8101d6039bb8
ffff8101d6039af8
[ 2190.059364] Call Trace:
[ 2190.059364] [<ffffffff8031ee6c>] ? sscanf+0x49/0x51
[ 2190.059364] [<ffffffffa0217b2b>] ? :9pnet:parse_opts+0xbf/0xcc
[ 2190.059364] [<ffffffff8027684e>] ? __alloc_pages_internal+0xd6/0x3bf
[ 2190.059364] [<ffffffffa021912f>] ? :9pnet:p9_trans_create_tcp+0x51/0x1d6
[ 2190.059364] [<ffffffff803208fb>] ? match_token+0x6d/0x1d2
[ 2190.059364] [<ffffffffa0215610>] ? :9pnet:p9_client_create+0x181/0x2b3
[ 2190.059364] [<ffffffff803208fb>] ? match_token+0x6d/0x1d2
[ 2190.059364] [<ffffffffa022475a>] ? :9p:v9fs_session_init+0x289/0x32f
[ 2190.059364] [<ffffffff8027684e>] ? __alloc_pages_internal+0xd6/0x3bf
[ 2190.059364] [<ffffffffa02230ec>] ? :9p:v9fs_get_sb+0x6d/0x1d9
[ 2190.059364] [<ffffffff8029cbbc>] ? vfs_kern_mount+0x93/0x11b
[ 2190.059364] [<ffffffff8029cc97>] ? do_kern_mount+0x43/0xdc
[ 2190.059364] [<ffffffff802b16a9>] ? do_new_mount+0x5b/0x95
[ 2190.059364] [<ffffffff802b18a0>] ? do_mount+0x1bd/0x1e7
[ 2190.059364] [<ffffffff8027684e>] ? __alloc_pages_internal+0xd6/0x3bf
[ 2190.059364] [<ffffffff802b1954>] ? sys_mount+0x8a/0xce
[ 2190.059364] [<ffffffff8020beca>] ? system_call_after_swapgs+0x8a/0x8f
[ 2190.059364]
[ 2190.059364]
[ 2190.059364] Code: 8d 74 24 10 4c 89 e7 48 8b 19 e8 fc f4 ff ff 89
03 48 8b 44 24 10 41 ff c5 48 85 c0 74 18 49 89 c4 48 8b 14 24 8a 02
84 c0 74 47 <41> 80 3c 24 00 0f 85 16 fa ff ff 48 8b 04 24 80 38 25 75
33 80
[ 2190.060321] RIP [<ffffffff8031edcc>] vsscanf+0x600/0x657
[ 2190.060321] RSP <ffff8101d6039a90>
[ 2190.060321] CR2: 0000000000000000
[ 2190.064870] ---[ end trace 9deab910d1f789fc ]---

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

Root Cause:

The root cause of this issue lies in the improper handling of options
parsing in the parse_opts function within the 9pnet module, as
indicated by the stack trace. Specifically, the crash occurs due to a
NULL pointer dereference in the vsscanf function while attempting to
parse the options provided during a mount system call. The PoC
triggers this by providing malformed or incomplete options for the 9p
filesystem mount with the trans=tcp parameter. The lack of adequate
validation and error handling in the parse_opts function leads to the
dereferencing of a NULL pointer when attempting to read an invalid or
missing field, causing a kernel panic. This highlights a vulnerability
in the kernel's option parsing logic for the 9P transport, resulting
in instability when exposed to crafted input.

Thank you for your time and attention.

Best regards

Wall

Powered by blists - more mailing lists