netdev - Re: [PATCH 1/2] hp100: Fix a possible sleep-in-atomic bug in hp100_login_to_vg

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20171213.162032.129766742729458957.davem@davemloft.net>
Date:   Wed, 13 Dec 2017 16:20:32 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     baijiaju1990@...il.com
Cc:     perex@...ex.cz, floeff@...hematik.uni-stuttgart.de,
        acme@...ectiva.com.br, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] hp100: Fix a possible sleep-in-atomic bug in
 hp100_login_to_vg_hub

I want you to review all of your patches and resend them after you
have checked them carefully.

The first patch I even looked at, this one, is buggy.

You changed a schedule_timeout_interruptible(1) into a udelay(10)

That's not right.

schedule_timeout_interruptible() takes a "jiffies" argument, which
is a completely different unit than udelay() takes.  You would have
to scale the argument to udelay() in some way using HZ.

Furthermore, the udelay argument you would come up with would
be way too long to be appropirate in this atomic context.

That's why the code tries to use a sleeping timeout, a long wait is
necessary here.