linux-kernel - Re: [PATCH] printk: fix buffer overflow potential for print

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

Message-ID: <YAbO6tQelFISgovf@alley>
Date:   Tue, 19 Jan 2021 13:22:02 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] printk: fix buffer overflow potential for print_text()

On Tue 2021-01-19 12:50:47, John Ogness wrote:
> On 2021-01-19, Sergey Senozhatsky <sergey.senozhatsky@...il.com> wrote:
> >>> John, how did you spot these problems?
> >> 
> >> I am preparing my series to remove the logbuf_lock, which also
> >> refactors and consolidates code from syslog_print_all() and
> >> kmsg_dump_get_buffer(). While testing/verifying my series, I noticed
> >> the these oddities in the semantics and decided I should research
> >> where they came from and if they were actually necessary.
> >
> > Any chance you can put those tests somewhere public so that we can
> > run them regularly?

Great idea.

> I have a collection of hacked-together tools that I use to test most of
> the various interfaces of printk. I would need to clean them up if they
> should be used for any kind of automated regression testing.

Sounds good. We could even help with the clean up. This kind of code
always need it when it was not written for public use from scratch.

> And where should I make such things available? I could put them in a
> repo in the Linutronix github account (like I did for the ringbuffer
> stress testing tool). (??)

Sounds good as well.

Best Regards,
Petr