"Bug in vsscanf" in Linux kernel Version 2.6.26

[cheung wall]

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