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]
Date:   Fri, 29 Mar 2019 04:09:22 +0100
From:   Marek Behun <>
To:     Greg Kroah-Hartman <>,
        Tejun Heo <>
Cc:, Pavel Machek <>,
        Jacek Anaszewski <>
Subject: kernfs: can read/write method grow buffer size?

Hello Tejun and Greg,

kernfs_fop_open/read/write allocates a buffer for the ->read, ->write,
or ->seq_read methods. This buffer is either preallocated or allocated
on the spot, with minimum size being PAGE_SIZE, if ->atomic_write_len
is not given.

There is a question/problem currently in the led-trigger API, that the
PAGE_SIZE buffer can in some specific scenarios be too short.
(The trigger file on read returns space separated list of all supported
triggers, and the currently chosen one is marked specially. The cpu
activity trigger lists "cpu%i" for all CPU cores, which actually broke
on some machines with very large number of CPUs. Granted, this could
have been solved another way (and maybe will be), but we are now
discussing API for HW LED triggers, which can raise the problem anyway,
if a specific LED controller supports too many HW LED triggers.)

Is it allowed to grow this buffer if needed, either via krealloc or by
creating a special function in kernfs API which does this so that
led-trigger could use it?

Or is this completely forbidden?

Thank you.


Powered by blists - more mailing lists