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: <YA7Y1WIjM3Oy2O7Y@alley>
Date:   Mon, 25 Jan 2021 15:42:29 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        John Ogness <john.ogness@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
        Sven Schnelle <svens@...ux.ibm.com>
Subject: [GIT PULL] printk urgent fix for 5.11-rc6

Linus,

please pull an urgent fixup from

  git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux.git tags/printk-for-5.11-urgent-fixup

===============================

- Prevent writing the trailing '\0' past the reader buffer.

===============================

The fix of a potential buffer overflow in 5.11-rc5 introduced another one.
The trailing '\0' might be written up to the message "len" past the buffer.
Fortunately, it is not that easy to hit[*].

Most readers use 1kB buffers for a single message. Typical messages fit into
the temporary buffer with enough reserve.

Also readers do not rely on the '\0'. It is related to the previous
fix. Some readers required the space for the trailing '\0'. We decided
to write it there to avoid such regressions in the future.

The most realistic victims are message dumpers using kmsg_dump_get_buffer().
They are filling the entire buffer with as many messages as possible. They
are typically used when handling panic().

The problem has been reported twice by a test suite and a robot:
https://lore.kernel.org/r/yt9dk0s48y70.fsf@linux.ibm.com
https://lore.kernel.org/r/000000000000bc67d205b9b8feb2@google.com

[*] This is not an excuse for such a mistake. We really should have caught
    it during development,review, or testing.

----------------------------------------------------------------
John Ogness (1):
      printk: fix string termination for record_print_text()

Petr Mladek (1):
      Merge branch 'printk-rework' into for-linus

 kernel/printk/printk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ