linux-kernel - Re: [PATCH] mm/kmemleak: Fix sleeping function called from invalid context in kmemleak_seq

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

Message-ID: <CAGegRW4B5PO0HgY1TvsV_R0hPSa5vHk7f=fy0skMpcy+BT399Q@mail.gmail.com>
Date: Thu, 21 Nov 2024 17:50:06 +0100
From: Alessandro Carminati <acarmina@...hat.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: Steven Rostedt <rostedt@...dmis.org>, Catalin Marinas <catalin.marinas@....com>, 
	Andrew Morton <akpm@...ux-foundation.org>, Clark Williams <clrkwllms@...nel.org>, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org, linux-rt-devel@...ts.linux.dev, 
	Thomas Weissschuh <thomas.weissschuh@...utronix.de>, 
	Alessandro Carminati <alessandro.carminati@...il.com>, Juri Lelli <juri.lelli@...hat.com>, 
	Gabriele Paoloni <gpaoloni@...hat.com>, Eric Chanudet <echanude@...hat.com>
Subject: Re: [PATCH] mm/kmemleak: Fix sleeping function called from invalid
 context in kmemleak_seq_show

Hello Sebastian,

On Wed, Nov 20, 2024 at 5:40 PM Sebastian Andrzej Siewior
<bigeasy@...utronix.de> wrote:
>
> On 2024-11-20 10:26:02 [-0500], Steven Rostedt wrote:
> > The "%pK" dereferences a pointer and there's some SELinux hooks attached to
> > that code. The problem is that the SELinux hooks take spinlocks. This would
> > not have been an issue if it wasn't for that "%pK" in the format.
>
> That is missing check and I think Thomas Weissschuh wanted to add it. So
> we don't call into selinux.

Your comment confuses me a bit, as I'm unsure what Thomas is actually
working on.
Am I correct in assuming he's addressing a fix in lib/vsprintf.c to ensure
that sleeping functions aren't called, allowing these functions to work in
any context?
However, his mention of "This fix for kmemleak is still needed as the
pointers in the kmemleak report are useful" adds to my confusion.
Meanwhile, Steven suggests reworking SELinux to resolve the issue.
Could you clarify what you mean by "So we don't call into selinux"?

>
> Sebastian
>

Thanks
-- 
---
172