linux-kernel - RE: [PATCH] kernfs: move return value check after kmalloc()

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

Date:   Fri, 21 May 2021 12:55:30 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Austin Kim' <austindh.kim@...il.com>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "tj@...nel.org" <tj@...nel.org>, "neilb@...e.de" <neilb@...e.de>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "austin.kim@....com" <austin.kim@....com>
Subject: RE: [PATCH] kernfs: move return value check after kmalloc()

From: Austin Kim
> Sent: 21 May 2021 03:55
> 
> With 414985ae23c0 ("sysfs, kernfs: move file core code to fs/kernfs/file.c"),
> 'return -ENOMEM' is executed when kmalloc() returns NULL.
> 
> Since 'commit 4ef67a8c95f3 ("sysfs/kernfs: make read requests on pre-alloc
> files use the buffer.")', 'return -ENOMEM' statement is not properly located.

Much more interesting is that the read is bounded to PAGE_SIZE
but the buffer is of->atomic_write_len bytes long.

Seems far too easy for the read() function to overwrite the buffer.
Either that, or you can have files longer than PAGE_SIZE that you
can write but not read all of!

There is also the question of whether the atomic operations
needed lock and unlock the preallocated buffer are actually
slower than kmalloc removing a buffer from a cpu-local list.

And, of course, kmalloc(PAGE_SIZE + 1, ) is horrid...

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)