Re: [PATCH v4 16/35] mm: slub: Unpoison the memchr_inv() return value

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2024-06-18 at 16:38 +0200, Alexander Potapenko wrote:
> On Thu, Jun 13, 2024 at 5:39 PM Ilya Leoshkevich <iii@xxxxxxxxxxxxx>
> wrote:
> > 
> > Even though the KMSAN warnings generated by memchr_inv() are
> > suppressed
> > by metadata_access_enable(), its return value may still be
> > poisoned.
> > 
> > The reason is that the last iteration of memchr_inv() returns
> > `*start != value ? start : NULL`, where *start is poisoned. Because
> > of
> > this, somewhat counterintuitively, the shadow value computed by
> > visitSelectInst() is equal to `(uintptr_t)start`.
> > 
> > The intention behind guarding memchr_inv() behind
> > metadata_access_enable() is to touch poisoned metadata without
> > triggering KMSAN, so unpoison its return value.
> 
> What do you think about applying __no_kmsan_checks to these functions
> instead?

Ok, will do. The __no_kmsan_checks approach is already taken by
"mm: kfence: Disable KMSAN when checking the canary", so we might as
well be consistent in how we fix these issues.





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux