[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210122165545.GJ3863@horizon.localdomain>
Date: Fri, 22 Jan 2021 13:55:45 -0300
From: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Daniel Borkmann <daniel@...earbox.net>,
Stanislav Fomichev <sdf@...gle.com>,
Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH 5.4 29/33] net, sctp, filter: remap copy_from_user
failure error
On Fri, Jan 22, 2021 at 03:12:45PM +0100, Greg Kroah-Hartman wrote:
> From: Daniel Borkmann <daniel@...earbox.net>
>
> [ no upstream commit ]
>
> Fix a potential kernel address leakage for the prerequisite where there is
> a BPF program attached to the cgroup/setsockopt hook. The latter can only
> be attached under root, however, if the attached program returns 1 to then
> run the related kernel handler, an unprivileged program could probe for
> kernel addresses that way. The reason this is possible is that we're under
> set_fs(KERNEL_DS) when running the kernel setsockopt handler. Aside from
> old cBPF there is also SCTP's struct sctp_getaddrs_old which contains
> pointers in the uapi struct that further need copy_from_user() inside the
> handler. In the normal case this would just return -EFAULT, but under a
> temporary KERNEL_DS setting the memory would be copied and we'd end up at
> a different error code, that is, -EINVAL, for both cases given subsequent
> validations fail, which then allows the app to distinguish and make use of
> this fact for probing the address space. In case of later kernel versions
> this issue won't work anymore thanks to Christoph Hellwig's work that got
> rid of the various temporary set_fs() address space overrides altogether.
> One potential option for 5.4 as the only affected stable kernel with the
> least complexity would be to remap those affected -EFAULT copy_from_user()
> error codes with -EINVAL such that they cannot be probed anymore. Risk of
> breakage should be rather low for this particular error case.
>
> Fixes: 0d01da6afc54 ("bpf: implement getsockopt and setsockopt hooks")
> Reported-by: Ryota Shiga (Flatt Security)
> Signed-off-by: Daniel Borkmann <daniel@...earbox.net>
> Cc: Stanislav Fomichev <sdf@...gle.com>
> Cc: Eric Dumazet <edumazet@...gle.com>
> Cc: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
For sctp bits,
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
...
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -1319,7 +1319,7 @@ static int __sctp_setsockopt_connectx(st
>
> kaddrs = memdup_user(addrs, addrs_size);
> if (IS_ERR(kaddrs))
> - return PTR_ERR(kaddrs);
> + return PTR_ERR(kaddrs) == -EFAULT ? -EINVAL : PTR_ERR(kaddrs);
>
> /* Allow security module to validate connectx addresses. */
> err = security_sctp_bind_connect(sk, SCTP_SOCKOPT_CONNECTX,
>
>
Powered by blists - more mailing lists