Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 17 Jan 2019 18:07:03 +0000
From: Nadav Amit <>
To: Masami Hiramatsu <>
CC: Rick Edgecombe <>, Andy Lutomirski
	<>, Ingo Molnar <>, Linux List Kernel Mailing
	<>, the arch/x86 maintainers <>,
	"H. Peter Anvin" <>, Thomas Gleixner <>,
	Borislav Petkov <>, Dave Hansen <>,
	Peter Zijlstra <>, Damian Tometzki
	<>, linux-integrity <>,
	LSM List <>, Andrew Morton
	<>, Kernel Hardening
	<>, Linux-MM <>, Will
 Deacon <>, Ard Biesheuvel <>,
	"" <>,
	"" <>
Subject: Re: [PATCH 17/17] module: Prevent module removal racing with

> On Jan 16, 2019, at 11:54 PM, Masami Hiramatsu <> wrote:
> On Wed, 16 Jan 2019 16:32:59 -0800
> Rick Edgecombe <> wrote:
>> From: Nadav Amit <>
>> It seems dangerous to allow code modifications to take place
>> concurrently with module unloading. So take the text_mutex while the
>> memory of the module is freed.
> At that point, since the module itself is removed from module list,
> it seems no actual harm. Or would you have any concern?

So it appears that you are right and all the users of text_poke() and
text_poke_bp() do install module notifiers, and remove the module from their
internal data structure when they are done (*). As long as they prevent
text_poke*() to be called concurrently (e.g., using jump_label_lock()),
everything is fine.

Having said that, the question is whether you “trust” text_poke*() users to
do so. text_poke() description does not day explicitly that you need to
prevent modules from being removed.

What do you say?

(*) I am not sure about kgdb, but it probably does not matter much

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.