On 06/24/14 11:48, Lai Jiangshan wrote:
>
> 326cf0f0f308 ("idr: fix top layer handling") enlarged the pa array.
> But the additional "+1" space is only used in id-allocation, it is free
> in other usage, (paa may point to the additional "+1" space, but not
> dereference it).
> so you can reuse it
326cf0f0f308 ("idr: fix top layer handling") enlarged the pa array.
But the additional "+1" space is only used in id-allocation, it is free
in other usage, (paa may point to the additional "+1" space, but not
dereference it).
so you can reuse it.
In the 3 functions your patch touched:
- st
On 06/24/14 05:26, Lai Jiangshan wrote:
> On 06/23/2014 09:37 PM, Andrey Ryabinin wrote:
>> I'm working on address sanitizer project for kernel. Recently we started
>> experiments with stack instrumentation, to detect out-of-bounds
>> read/write bugs on stack.
>>
>> Just after booting I've hit out-
On 06/23/2014 09:37 PM, Andrey Ryabinin wrote:
> I'm working on address sanitizer project for kernel. Recently we started
> experiments with stack instrumentation, to detect out-of-bounds
> read/write bugs on stack.
>
> Just after booting I've hit out-of-bounds read on stack in idr_for_each
> (and
I'm working on address sanitizer project for kernel. Recently we started
experiments with stack instrumentation, to detect out-of-bounds
read/write bugs on stack.
Just after booting I've hit out-of-bounds read on stack in idr_for_each
(and in __idr_remove_all as well):
struct idr_layer **
5 matches
Mail list logo