linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Austin Kim' <austindh.kim@gmail.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"tj@kernel.org" <tj@kernel.org>, "neilb@suse.de" <neilb@suse.de>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"austin.kim@lge.com" <austin.kim@lge.com>
Subject: RE: [PATCH] kernfs: move return value check after kmalloc()
Date: Fri, 21 May 2021 12:55:30 +0000	[thread overview]
Message-ID: <b698a7530ce747d180e93967572d3d88@AcuMS.aculab.com> (raw)
In-Reply-To: <20210521025525.GA1379@raspberrypi>

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)


      parent reply	other threads:[~2021-05-21 12:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-21  2:55 [PATCH] kernfs: move return value check after kmalloc() Austin Kim
2021-05-21  3:28 ` NeilBrown
2021-05-21  4:39 ` Greg KH
2021-05-21  6:55   ` Austin Kim
2021-05-21 12:15     ` David Laight
2021-05-21 12:55 ` David Laight [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b698a7530ce747d180e93967572d3d88@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=austin.kim@lge.com \
    --cc=austindh.kim@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).