linux-kernel - [Question] [sched/fair] can vma be unmapped when somewhere inside task_numa

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: <CAOAOcWt4p8ng6yxod0wU4XZfOcT=UFTuzaFxWd4rsfU=H3_FVQ@mail.gmail.com>
Date: Sat, 16 Nov 2024 10:26:19 +0530
From: shaarang tyagi <shaarang.tyagi@...il.com>
To: "tglx@...utronix.de" <tglx@...utronix.de>, linux-kernel@...r.kernel.org
Subject: [Question] [sched/fair] can vma be unmapped when somewhere inside task_numa_work

Hello,

In the file sched/fair.c  in the function: task_numa_work(struct
callback_head *work)
My question is that is it possible that vma is unmapped(concurrently)
after the null check in the for loop has succeeded ?
Will it cause a dangling vma pointer?

For example right at the starting of the do..while(end != vma->end) loop.
Or vma is unmapped right before where we dereference 'vma->vm_file'.

Best Regards,
Shaarang