linux-kernel - Re: [PATCH V3] block, bfq: fix use-after-free in bfq_idle_slice_timer

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: <1052be18-ef45-e254-e1bb-09a7cd6d891f@kernel.dk>
Date:   Sat, 21 Mar 2020 14:29:57 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Zhiqiang Liu <liuzhiqiang26@...wei.com>, paolo.valente@...aro.org
Cc:     linux-block <linux-block@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Mingfangsen <mingfangsen@...wei.com>, yanxiaodan@...wei.com,
        "wubo (T)" <wubo40@...wei.com>, renxudong <renxudong1@...wei.com>,
        Louhongxiang <louhongxiang@...wei.com>, linfeilong@...wei.com,
        wangwang2@...wei.com
Subject: Re: [PATCH V3] block, bfq: fix use-after-free in
 bfq_idle_slice_timer_body

On 3/19/20 5:18 AM, Zhiqiang Liu wrote:
> 
> In bfq_idle_slice_timer func, bfqq = bfqd->in_service_queue is
> not in bfqd-lock critical section. The bfqq, which is not
> equal to NULL in bfq_idle_slice_timer, may be freed after passing
> to bfq_idle_slice_timer_body. So we will access the freed memory.
> 
> In addition, considering the bfqq may be in race, we should
> firstly check whether bfqq is in service before doing something
> on it in bfq_idle_slice_timer_body func. If the bfqq in race is
> not in service, it means the bfqq has been expired through
> __bfq_bfqq_expire func, and wait_request flags has been cleared in
> __bfq_bfqd_reset_in_service func. So we do not need to re-clear the
> wait_request of bfqq which is not in service.

Applied, thanks.

-- 
Jens Axboe