On 11/20/2014 12:03 PM, Ingo Molnar wrote:

* Andrey Ryabinin [off-list ref] wrote:

quoted

I've counted 16:

aab515d (fib_trie: remove potential out of bound access)
984f173 ([SCSI] sd: Fix potential out-of-bounds access)
5e9ae2e (aio: fix use-after-free in aio_migratepage)
2811eba (ipv6: udp packets following an UFO enqueued packet need also
be handled by UFO)
057db84 (tracing: Fix potential out-of-bounds in trace_get_user())
9709674 (ipv4: fix a race in ip4_datagram_release_cb())
4e8d213 (ext4: fix use-after-free in ext4_mb_new_blocks)
624483f (mm: rmap: fix use-after-free in __put_anon_vma)
93b7aca (lib/idr.c: fix out-of-bounds pointer dereference)
b4903d6 (mm: debugfs: move rounddown_pow_of_two() out from do_fault path)
40eea80 (net: sendmsg: fix NULL pointer dereference)
10ec947 (ipv4: fix buffer overflow in ip_options_compile())
dbf20cb2 (f2fs: avoid use invalid mapping of node_inode when evict meta inode)
d6d86c0 (mm/balloon_compaction: redesign ballooned pages management)

+ 2 recently found, seems minor:
    http://lkml.kernel.org/r/1415372020-1871-1-git-send-email-a.ryabinin@samsung.com
    (sched/numa: Fix out of bounds read in sched_init_numa())

    http://lkml.kernel.org/r/1415458085-12485-1-git-send-email-ryabinin.a.a@gmail.com
    (security: smack: fix out-of-bounds access in smk_parse_smack())

Note that some functionality is not yet implemented in this 
patch set. Kasan has possibility to detect out-of-bounds 
accesses on global/stack variables. Neither 
kmemcheck/debug_pagealloc or slub_debug could do that.

quoted

That's in a 20-year-old code base, so one new minor bug discovered per
three years?  Not worth it!

Presumably more bugs will be exposed as more people use kasan on
different kernel configs, but will their number and seriousness justify
the maintenance effort?

Yes, AFAIK there are only few users of kasan now, and I guess that
only small part of kernel code
was covered by it.
IMO kasan shouldn't take a lot maintenance efforts, most part of code
is isolated and it doesn't
have some complex dependencies on in-kernel API.
And you could always just poke me, I'd be happy to sort out any issues.

quoted

If kasan will permit us to remove kmemcheck/debug_pagealloc/slub_debug
then that tips the balance a little.  What's the feasibility of that?

I think kasan could replace kmemcheck at some point.

So that angle sounds interesting, because kmemcheck is 
essentially unmaintained right now: in the last 3 years since 
v3.0 arch/x86/mm/kmemcheck/ has not seen a single kmemcheck 
specific change, only 4 incidental changes.

kmemcheck is also very architecture bound and somewhat fragile 
due to having to decode instructions, so if generic, compiler 
driven instrumentation can replace it, that would be a plus.

GCC already supports address sanitizer on x86_32/x86_64/arm/arm64/rs6000,
and adding compiler's support for any other architecture is trivial.

Per-arch work on kernel-side maybe is not trivial, but there is nothing complex either.
It's much more simpler then kmemcheck.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>