linux-kernel - Re: [PATCH v5 1/3] random: add vgetrandom

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: <Y3k+/hSL5rIIkBhK@sol.localdomain>
Date:   Sat, 19 Nov 2022 12:39:26 -0800
From:   Eric Biggers <ebiggers@...nel.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     linux-kernel@...r.kernel.org, patches@...ts.linux.dev,
        linux-crypto@...r.kernel.org, x86@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>,
        Carlos O'Donell <carlos@...hat.com>
Subject: Re: [PATCH v5 1/3] random: add vgetrandom_alloc() syscall

On Sat, Nov 19, 2022 at 01:09:27PM +0100, Jason A. Donenfeld wrote:
> +SYSCALL_DEFINE3(vgetrandom_alloc, unsigned long __user *, num,
> +		unsigned long __user *, size_per_each, unsigned int, flags)
> +{
> +	unsigned long alloc_size;
> +	unsigned long num_states;
> +	unsigned long pages_addr;
> +	int ret;
> +
> +	if (flags)
> +		return -EINVAL;
> +
> +	if (get_user(num_states, num))
> +		return -EFAULT;
> +
> +	alloc_size = size_mul(num_states, sizeof(struct vgetrandom_state));
> +	if (alloc_size == SIZE_MAX)
> +		return -EOVERFLOW;
> +	alloc_size = roundup(alloc_size, PAGE_SIZE);

Small detail: the roundup to PAGE_SIZE can make alloc_size overflow to 0.

Also, 'roundup(alloc_size, PAGE_SIZE)' could be 'PAGE_ALIGN(alloc_size)'.

> +	pages_addr = vm_mmap(NULL, 0, alloc_size, PROT_READ | PROT_WRITE,
> +			     MAP_PRIVATE | MAP_ANONYMOUS | MAP_LOCKED, 0);
> +	if (IS_ERR_VALUE(pages_addr))
> +		return pages_addr;

This will only succeed if the userspace process has permission to mlock pages,
i.e. if there is space available in RLIMIT_MEMLOCK or if process has
CAP_IPC_LOCK.  I suppose this is working as intended, as this syscall can be
used to try to allocate and mlock arbitrary amounts of memory.

I wonder if this permission check will cause problems.  Maybe there could be a
way to relax it for just one page per task?  I don't know how that would work,
though, especially when the planned usage involves userspace allocating a single
pool of these contexts per process that get handed out to threads.

- Eric