linux-kernel - Re: [RFC PATCH] cocci: cpi: add complete api check script

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

Message-ID: <m2mt4z5adr.fsf@gmail.com>
Date:   Tue, 28 Feb 2023 00:36:26 +0800
From:   Schspa Shi <schspa@...il.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, cocci@...ia.fr, mcgrof@...nel.org,
        Julia Lawall <Julia.Lawall@...ia.fr>,
        Nicolas Palix <nicolas.palix@...g.fr>,
        Matthias Brugger <matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Ingo Molnar <mingo@...hat.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Valentin Schneider <vschneid@...hat.com>,
        buytenh@...tstofly.org, johannes.berg@...el.com,
        gregkh@...uxfoundation.org, tomba@...nel.org, airlied@...il.com,
        daniel@...ll.ch
Subject: Re: [RFC PATCH] cocci: cpi: add complete api check script


Steven Rostedt <rostedt@...dmis.org> writes:

> On Mon, 27 Feb 2023 16:43:59 +0100
> Peter Zijlstra <peterz@...radead.org> wrote:
>
>> On Mon, Feb 27, 2023 at 10:28:08AM -0500, Steven Rostedt wrote:
>> 
>> > So what exact race are you trying to catch here?  
>> 
>> on-stack copmletion with a wait_for_completion that can return early
>> (eg. killable, interruptible, or timeout) can go out of scope (eg, free
>> the completion) with the other side calling complete() on some possibly
>> re-used piece of stack.
>> 
>> IOW, Use-after-Free.
>> 
>> Care must be taken to ensure the other side (whatever does complete())
>> is either terminated or otherwise stopped from calling complete() on an
>> out-of-scope variable.
>
> I got that. But as you were stating as well, when care is taken, the script
> appears to still report it. The example I gave has:
>
>         req = blk_mq_alloc_request(q, REQ_OP_DRV_OUT, 0);
> [..]
>         req->end_io_data = &wait;
> [..]
>         hba->tmf_rqs[req->tag] = req;
> [..]
>         err = wait_for_completion_io_timeout(&wait,
> [..]
>         spin_lock_irqsave(hba->host->host_lock, flags);
>         hba->tmf_rqs[req->tag] = NULL;
>         __clear_bit(task_tag, &hba->outstanding_tasks);
>         spin_unlock_irqrestore(hba->host->host_lock, flags);
>
>
> And where the complete is:
>
>         spin_lock_irqsave(hba->host->host_lock, flags);
>         pending = ufshcd_readl(hba, REG_UTP_TASK_REQ_DOOR_BELL);
>         issued = hba->outstanding_tasks & ~pending;
>         for_each_set_bit(tag, &issued, hba->nutmrs) {
>                 struct request *req = hba->tmf_rqs[tag];
>                 struct completion *c = req->end_io_data;
>  
>                 complete(c);
>                 ret = IRQ_HANDLED;
>         }
>         spin_unlock_irqrestore(hba->host->host_lock, flags);
>
> So the spinlock is making sure that the complete() only works on a
> completion if it is still there.
>
There is nothing wrong with your code.

This script will not check the hba->host->host_lock lock, and there is
another hba->outstanding_tasks bit mask to ensure that there is no UAF
here. But this script doesn't have a way to get these implicit
conditions.

> I guess I should have asked, how is this script differentiating between
> where there's a problem and where there isn't.
>
> If you remove the spinlocks, then there would most definitely be a race,
> and I'm not even sure if the supplied patch would improve this much.
>
> -- Steve


-- 
BRs
Schspa Shi