linux-kernel - Re: [PATCH] mm: fix (harmless) type confusion in lock_vma_under

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: <CAG48ez0LJGi_OGynxh3z8KNvDHVkVbENgGg_oPLzDCi=gJujzA@mail.gmail.com>
Date: Tue, 6 Aug 2024 18:20:17 +0200
From: Jann Horn <jannh@...gle.com>
To: Suren Baghdasaryan <surenb@...gle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Matthew Wilcox <willy@...radead.org>, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: fix (harmless) type confusion in lock_vma_under_rcu()

On Tue, Aug 6, 2024 at 6:14 PM Suren Baghdasaryan <surenb@...gle.com> wrote:
> On Mon, Aug 5, 2024 at 5:52 AM Jann Horn <jannh@...gle.com> wrote:
> >
> > There is a (harmless) type confusion in lock_vma_under_rcu():
> > After vma_start_read(), we have taken the VMA lock but don't know yet
> > whether the VMA has already been detached and scheduled for RCU freeing.
> > At this point, ->vm_start and ->vm_end are accessed.
> >
> > vm_area_struct contains a union such that ->vm_rcu uses the same memory as
> > ->vm_start and ->vm_end; so accessing ->vm_start and ->vm_end of a detached
> > VMA is illegal and leads to type confusion between union members.
> >
> > Fix it by reordering the vma->detached check above the address checks, and
> > document the rules for RCU readers accessing VMAs.
> >
> > This will probably change the number of observed VMA_LOCK_MISS events
> > (since previously, trying to access a detached VMA whose ->vm_rcu has been
> > scheduled would bail out when checking the fault address against the
> > rcu_head members reinterpreted as VMA bounds).
> >
> > Fixes: 50ee32537206 ("mm: introduce lock_vma_under_rcu to be used from arch-specific code")
> > Signed-off-by: Jann Horn <jannh@...gle.com>
>
> Thanks for fixing this subtle issue and clearly documenting the rules!
> Not sure if we should CC stable? It is harmless but it's still a bug...

Yeah, I'm not sure - I guess it kinda depends on how much we care
about VMA_LOCK_MISS being accurate?

> Acked-by: Suren Baghdasaryan <surenb@...gle.com>

Thanks!