linux-kernel - PROBLEM: in_atomic() misuse all over the place

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

Date:	Wed, 28 Jan 2009 00:10:37 +0100
From:	Roger Larsson <roger.larsson@...atan.se>
To:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Robert Love <rml@...h9.net>
Cc:	Pavel Machek <pavel@....cz>
Subject: PROBLEM: in_atomic() misuse all over the place

(resent, non html)

[1.] One line summary of the problem:    
in_atomic() is used to select path of execution, most likely to suppress 
warning logs when running a preemptive kernel.

[2.] Full description of the problem/report:

The problem is that in_atomic() only works on preemptive kernels...

Result: preemptive kernel warns about a potential deadlock in all kernels,
developer silence with the help of in_atomic()
bug remains in SMP/UP kernels...

[3.] Keywords (i.e., modules, networking, kernel):
in_atomic(), preemptive, sleeping

[4.] Kernel version (from /proc/version):
	2.6.28.2 (review)

[5.] Output of Oops..

"sleeping function called from invalid context"

[6.] A small shell script or example program which triggers the
     problem (if possible)

Small example of the strange code I found is this

file:  include/net/sock.h

   static inline gfp_t gfp_any(void)
   {
     return in_atomic() ? GFP_ATOMIC : GFP_KERNEL;
   }

	//  I can find no comment on why this strange code would be OK.
	//  An it is in its turn used in several drivers...

If the processor can get to this function while atomic in a preemptive kernel 
it will likely be able to get there in other kernels as well, especially SMP.

It returns GFP_ATOMIC when being atomic in a preemptive kernel, allocating 
with that flag will not sleep. But calling this with another kernel will 
ALWAYS return GFP_KERNEL, and it may cause a sleeping allocate...

Other places that I think misuse of in_atomic is Arch code, USB code, ...

There are 77 uses of in_atomic directly (grep | wc)
36 in ./arch
23 in ./drivers
2 in ./sound/core/seq/seq_virmidi.c
1 in ./include/net/sock.h
The remaining 15 are probably OK (kernel, mm/filemap)

But the sock.h gfp_any() spreads further...
1 in ./Documentation
2 in ./drivers
9 in ./net

Suggestion: should in_atomic() that by default return the safer 1 instead of 
the unsafe 0. And add an in_atomic_warn() with default of 0 to use where it is
OK - like when deciding to log a warning.

/RogerL

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/