single_open() requires the kernel to kmalloc a buffer which lives until
the userspace caller closes the file. What prevents a malicious user
opening the same /proc entry multiple times, allocating lots of kmalloc
space and causing a local DoS?
Keith Owens wrote:
>single_open() requires the kernel to kmalloc a buffer which lives until
>the userspace caller closes the file. What prevents a malicious user
>opening the same /proc entry multiple times, allocating lots of kmalloc
>space and causing a local DoS?
>
>
ulimit?
On Thu, Sep 11, 2003 at 02:42:13PM +1000, Keith Owens wrote:
> single_open() requires the kernel to kmalloc a buffer which lives until
> the userspace caller closes the file. What prevents a malicious user
> opening the same /proc entry multiple times, allocating lots of kmalloc
> space and causing a local DoS?
Size of that buffer is limited. IOW, it's not different from opening
e.g. a shitload of pipes or sockets.
On Thu, 11 Sep 2003 14:51:09 +1000,
Nick Piggin <[email protected]> wrote:
>Keith Owens wrote:
>
>>single_open() requires the kernel to kmalloc a buffer which lives until
>>the userspace caller closes the file. What prevents a malicious user
>>opening the same /proc entry multiple times, allocating lots of kmalloc
>>space and causing a local DoS?
>>
>>
>
>ulimit?
ulimit has no effect on kmalloc usage.
On Thu, 11 Sep 2003 05:55:07 +0100,
[email protected] wrote:
>On Thu, Sep 11, 2003 at 02:42:13PM +1000, Keith Owens wrote:
>> single_open() requires the kernel to kmalloc a buffer which lives until
>> the userspace caller closes the file. What prevents a malicious user
>> opening the same /proc entry multiple times, allocating lots of kmalloc
>> space and causing a local DoS?
>
>Size of that buffer is limited. IOW, it's not different from opening
>e.g. a shitload of pipes or sockets.
In some cases, the buffer size is set to hold _all_ of the output for
that particular /proc file and will be much larger than the data
reserved for files and sockets. It is a difference in scale.
fs/proc/proc_misc.c stat_open
fs/proc/proc_misc.c interrupts_open
kernel/dma.c proc_dma_open
All those functions will kmalloc a reasonably sized buffer then let the
user control the lifetime of that buffer. Looks like a recipe for a
local DoS to me.
On Thu, Sep 11, 2003 at 05:26:54PM +1000, Keith Owens wrote:
> On Thu, 11 Sep 2003 05:55:07 +0100,
> [email protected] wrote:
> >On Thu, Sep 11, 2003 at 02:42:13PM +1000, Keith Owens wrote:
> >> single_open() requires the kernel to kmalloc a buffer which lives until
> >> the userspace caller closes the file. What prevents a malicious user
> >> opening the same /proc entry multiple times, allocating lots of kmalloc
> >> space and causing a local DoS?
> >
> >Size of that buffer is limited. IOW, it's not different from opening
> >e.g. a shitload of pipes or sockets.
>
> In some cases, the buffer size is set to hold _all_ of the output for
> that particular /proc file and will be much larger than the data
> reserved for files and sockets. It is a difference in scale.
>
> fs/proc/proc_misc.c stat_open
> fs/proc/proc_misc.c interrupts_open
> kernel/dma.c proc_dma_open
>
> All those functions will kmalloc a reasonably sized buffer then let the
> user control the lifetime of that buffer. Looks like a recipe for a
> local DoS to me.
struct file: 256 bytes due to cacheline alignment
struct dentry: 128 bytes, IIRC
struct inode: either 256 bytes or 512 bytes.
struct socket and struct sock: bugger if I remember, but it's not small.
On Thu, Sep 11, 2003 at 05:04:48PM +1000, Keith Owens wrote:
> On Thu, 11 Sep 2003 14:51:09 +1000,
> Nick Piggin <[email protected]> wrote:
> >Keith Owens wrote:
> >
> >>single_open() requires the kernel to kmalloc a buffer which lives until
> >>the userspace caller closes the file. What prevents a malicious user
> >>opening the same /proc entry multiple times, allocating lots of kmalloc
> >>space and causing a local DoS?
> >>
> >>
> >
> >ulimit?
>
> ulimit has no effect on kmalloc usage.
You do realize that struct file is also kmalloc'ed? So are dentries and
inodes, for that matter. It's the same situation as with pipes and sockets.