linux-kernel - Re: [RFC v2] lis3lv02d: avoid divide by zero due to unchecked register read

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 May 2011 17:47:12 +0200
From:	Christian Lamparter <chunkeey@...glemail.com>
To:	Éric Piel <Eric.Piel@...mplin-utc.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC v2] lis3lv02d: avoid divide by zero due to unchecked register read

On Tuesday 17 May 2011 23:46:00 Éric Piel wrote:
> Op 16-05-11 23:36, Christian Lamparter schreef:
> > On Monday 16 May 2011 13:16:46 Éric Piel wrote:
> >> Op 16-05-11 00:46, Christian Lamparter schreef:
> >>>  From my POV, it looks like the hardware is not working as expected
> >>> and returns a bogus data rate. The driver doesn't check the result
> >>> and directly uses it as some sort of divisor in some places:
> >>>
> >>> msleep(lis3->pwron_delay / lis3lv02d_get_odr());
> >>>
> >>> Under this circumstances, this could very well cause the
> >>> "divide by zero" exception from above.
> >>>
> >> However, I'd fix it a bit differently: let lis3lv02d_get_odr() return
> >> the raw data, and create a special function
> >> lis3lv02d_get_pwron_delay_ms() which does the "lis3->pwron_delay /
> >> lis3lv02d_get_odr()" with special handling for 0 (returning a large
> >> value and also sending a printk_once() ).
> > Do you know how "volatile" this data rate is? If it never changes
> > [at least it doesn't here?] then why not read it once in init_device
> > and store it in the device context?
> It is not normally changing, normally it is set just at init/unsuspend 
> (where the bios can also interfere sometimes) and when the user changes 
> it.
Uh, "bios can also interfere"... this sounds very bad. At least for
my x41t the bios doesn't care about hdaps once the OS is running.

> So definitely within the same function it's not going to suddenly 
> change.
a SMM can happen at any time and if a faulty BIOS [likely, since I got
a new laptop] is what caused the crash, I wouldn't bet on "const within
a function context".

> We could avoid calculating/checking it twice in 
> lis3lv02d_selftest(). Care to do a third version with this little clean up?
I have my doubts, but ok if you say so... Just one thing: need to do some Q&A
on the code above, I haven't tested it extensively yet.

Regards,
	Chr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/