From: "Theo de Raadt" <[email protected]>
Date: Tue, 04 Oct 2022 21:58:13 -0600
> Looking at these pieces:
>
> + sc->sc_rpc_buf = malloc(sc->sc_rpc_buflen, M_DEVBUF, M_NOWAIT);
> ...
> +vm_rpc_buf_realloc(struct vmt_softc *sc, size_t len)
> +{
> + free(sc->sc_rpc_buf, M_DEVBUF, sc->sc_rpc_buflen);
> +
> + sc->sc_rpc_buflen = len / VMT_RPC_BUFLEN * VMT_RPC_BUFLEN;
> + sc->sc_rpc_buflen += ((len % VMT_RPC_BUFLEN) <= 0) ? 0 :
> VMT_RPC_BUFLEN;
> + sc->sc_rpc_buf = malloc(sc->sc_rpc_buflen, M_DEVBUF, M_NOWAIT);
> ...
> + else if (srclen > SIZE_T_MAX)
> return (ENAMETOOLONG);
>
> *dstp = dst = malloc(srclen + 1, M_TEMP|M_ZERO, M_WAITOK);
>
> Userland may not ask the kernel to allocate such a huge object. The
> kernel address space is quite small. First off, huge allocations will
> fail.
>
> But it is worse -- the small kernel address space is shared for many
> purposes, so large allocations will harm the other subsystems.
>
> As written, this diff is too dangerous. Arbitrary allocation inside
> the kernel is not reasonable. object sizes requested by userland must
> be small, or the operations must be cut up, which does create impact
> on atomicity or other things.
As you pointed out, it is not a good idea to allocate large spaces
in kernel.
Would it be better to keep the current fixed length?
Prepare a variable like kern.maxpvbus and default it to
4096. Futhermore, how about free() after copyout() to user space?
Thank you.
--
ASOU Masato
