linux-kernel - Re: [PATCH] kfence: check kfence canary in panic and reboot

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

Message-ID: <20220421121018.60860-1-huangshaobo6@huawei.com>
Date:   Thu, 21 Apr 2022 20:10:18 +0800
From:   Shaobo Huang <huangshaobo6@...wei.com>
To:     <glider@...gle.com>
CC:     <akpm@...ux-foundation.org>, <chenzefeng2@...wei.com>,
        <dvyukov@...gle.com>, <elver@...gle.com>,
        <huangshaobo6@...wei.com>, <kasan-dev@...glegroups.com>,
        <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
        <nixiaoming@...wei.com>, <wangbing6@...wei.com>,
        <wangfangpeng1@...wei.com>, <young.liuyang@...wei.com>,
        <zengweilin@...wei.com>, <zhongjubin@...wei.com>
Subject: Re: [PATCH] kfence: check kfence canary in panic and reboot

> > From: huangshaobo <huangshaobo6@...wei.com>
> >
> > when writing out of bounds to the red zone, it can only be detected at
> > kfree. However, there were many scenarios before kfree that caused this
> > out-of-bounds write to not be detected. Therefore, it is necessary to
> > provide a method for actively detecting out-of-bounds writing to the red
> > zone, so that users can actively detect, and can be detected in the
> > system reboot or panic.
> >
> >
> After having analyzed a couple of KFENCE memory corruption reports in the
> wild, I have doubts that this approach will be helpful.
> 
> Note that KFENCE knows nothing about the memory access that performs the
> actual corruption.
> 
> It's rather easy to investigate corruptions of short-living objects, e.g.
> those that are allocated and freed within the same function. In that case,
> one can examine the region of the code between these two events and try to
> understand what exactly caused the corruption.
> 
> But for long-living objects checked at panic/reboot we'll effectively have
> only the allocation stack and will have to check all the places where the
> corrupted object was potentially used.
> Most of the time, such reports won't be actionable.
 
The detection mechanism of kfence is probabilistic. It is not easy to find a bug.
It is a pity to catch a bug without reporting it. and the cost of panic detection
is not large, so panic detection is still valuable.
 
> > for example, if the application memory is out of bounds and written to
> > the red zone in the kfence object, the system suddenly panics, and the
> > following log can be seen during system reset:
> > BUG: KFENCE: memory corruption in atomic_notifier_call_chain+0x49/0x70
[...]

thanks,
ShaoBo Huang