linux-kernel - Crashing 'kzm' target in next-20160913 due to 'gpio: mxc: shift gpio_mxc_init() to subsys

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: <9befb559-499a-dd70-cd44-60d5fce2e5d6@roeck-us.net>
Date:   Tue, 13 Sep 2016 20:20:35 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>,
        Shawn Guo <shawnguo@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>
Subject: Crashing 'kzm' target in next-20160913 due to 'gpio: mxc: shift
 gpio_mxc_init() to subsys_initcall level'

Hi Vladimir,

your commit e188cbf7564f ("gpio: mxc: shift gpio_mxc_init() to subsys_initcall level")
in -next causes the following crash when running the 'kzm' target (and most likely
the real thing) with qemu.

[    1.211426] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
[    1.211600] pgd = c0004000
[    1.211680] [0000000c] *pgd=00000000
[    1.212067] Internal error: Oops: 5 [#1] SMP ARM
[    1.212245] Modules linked in:
[    1.212542] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc6-next-20160913 #1
[    1.212671] Hardware name: Kyoto Microcomputer Co., Ltd. KZM-ARM11-01
[    1.212825] task: c6848000 task.stack: c683e000
[    1.213231] PC is at platform_get_irq+0xc0/0xe8

See http://kerneltests.org/builders/qemu-arm-next/builds/525/steps/qemubuildcommand/logs/stdio
for a complete log.

Problem is quite subtle. The change causes the gpio driver to be installed later.
As a result, kzm_init_smsc9118() fails to initialize the gpio pins correctly.
gpio_request() in that function returns -EPROBE_DEFER, which is ignored,
gpio_to_irq() then returns -22 which is unconditionally assigned as interrupt number.
platform_get_irq(), as called from the smsc driver, gets this negative interrupt
number, and passes it unconditionally to irq_get_irq_data(), which returns NULL.
The NULL pointer is then passed to irqd_set_trigger_type() which, not entirely
surprisingly, crashes.

So, in other words, lots of bugs here. Nevertheless, I would suggest to keep using
postcore_initcall(), at least until it is sure that all gpio clients handle -EPROBE_DEFER
correctly.

Thanks,
Guenter