linux-kernel - kernel/printk/printk.c: Invalid access when buffer wraps around?

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]

Message-ID: <89c15437-5a97-68b1-d83f-097f3b047559@cern.ch>
Date:	Mon, 25 Jul 2016 11:22:24 +0200
From:	Vincent Brillault <vincent.brillault@...n.ch>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	Petr Mladek <pmladek@...e.com>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Andrey Ryabinin <aryabinin@...tuozzo.com>,
	Kees Cook <keescook@...omium.org>,
	Thierry Reding <treding@...dia.com>,
	Geliang Tang <geliangtang@....com>, Tejun Heo <tj@...nel.org>,
	Ivan Delalande <colona@...sta.com>
CC:	<linux-kernel@...r.kernel.org>
Subject: kernel/printk/printk.c: Invalid access when buffer wraps around?

Dear all,

First of all, I'm sorry to send you this direct email, but it seems that
there is no entry for kernel/printk/printk.c in MAINTAINERS, so I can
only notify you, who have touched this part of the code...

While working on a kernel module that basically forks
kernel/printk/printk.c to create its own buffer, I believe I have found
a bug in how printk wraps around its buffer: In a very specific case, a
reader, trying to read what was supposed to be a zeroed header
indicating that the buffer wrapped, might read random data from another
message that has overridden it. The root of the problems seems to be
that the zeroed header placed at the end of the buffer is not protected
by the sequence number checks.

I've attached two files to this email:
- An explanation of the bug, including key parts of the code.
- A simplified example on how the bug can be triggered.

I believe that this bug is very difficult to trigger and, as a user
don't have proper control on the content of the printk buffer, it can at
most lead to a kernel panic in some very unfortunate circumstances.

Sincerely yours,
Vincent Brillault

View attachment "printk.bug.explanations.txt" of type "text/plain" (6233 bytes)

View attachment "printk.bug.example.txt" of type "text/plain" (1874 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)