linux-kernel - Re: [PATCH] isdn: mISDN: tei: Fix a sleep-in-atomic-context bug in create

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

Message-ID: <c7562383-8255-31f4-8f91-057011172b65@gmail.com>
Date:   Mon, 3 Sep 2018 09:40:10 +0800
From:   Jia-Ju Bai <baijiaju1990@...il.com>
To:     isdn@...ux-pingi.de
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] isdn: mISDN: tei: Fix a sleep-in-atomic-context bug in
 create_teimgr()



On 2018/9/3 0:31, isdn@...ux-pingi.de wrote:
> Hi,
>
> I do not understand the analysis and do not see that the spinlock is a
> problem here.
> I think your DSAC analyzer assumes that the FUNC_PTR mgr_ctrl call calls
> the  mgr_ctrl in tei.c, but in real it calls l2->ch.ctrl() which is the
> function in layer2.c, not tei.c. And the function in layer2.c should not
> do any GFP_KERNEL allocation.
>
> Same for your 2. reported issue.

Okay, thanks for your reply.
My analysis handles the function pointer using the function type and 
structure field, but it cannot distinguish the different variables of 
the same type and field now.
I will try to improve my tool, thanks for your explanation.


Best wishes,
Jia-Ju Bai