This patch is a small change in enforcement of the uapi for
SECCOMP_IOCTL_NOTIF_RECV ioctl. Specifically, the datastructure which
is passed (seccomp_notif) must be zeroed out. Previously any of its
members could be set to nonsense values, and we would ignore it.
This ensures all fields are set to their zero value.
This relies on the seccomp_notif datastructure to not have
any unnamed padding, as it is valid to initialize the datastructure
as:
struct seccomp_notif notif = {};
This only initializes named members to their 0-value [1].
[1]: https://lore.kernel.org/lkml/[email protected]/
Signed-off-by: Sargun Dhillon <[email protected]>
Cc: Kees Cook <[email protected]>
---
kernel/seccomp.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 12d2227e5786..4fd73cbdd01e 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -1026,6 +1026,12 @@ static long seccomp_notify_recv(struct seccomp_filter *filter,
struct seccomp_notif unotif;
ssize_t ret;
+ ret = check_zeroed_user(buf, sizeof(unotif));
+ if (ret < 0)
+ return ret;
+ if (!ret)
+ return -EINVAL;
+
memset(&unotif, 0, sizeof(unotif));
ret = down_interruptible(&filter->notif->request);
--
2.20.1
On 2019-12-28, Sargun Dhillon <[email protected]> wrote:
> This patch is a small change in enforcement of the uapi for
> SECCOMP_IOCTL_NOTIF_RECV ioctl. Specifically, the datastructure which
> is passed (seccomp_notif) must be zeroed out. Previously any of its
> members could be set to nonsense values, and we would ignore it.
>
> This ensures all fields are set to their zero value.
>
> This relies on the seccomp_notif datastructure to not have
> any unnamed padding, as it is valid to initialize the datastructure
> as:
>
> struct seccomp_notif notif = {};
>
> This only initializes named members to their 0-value [1].
>
> [1]: https://lore.kernel.org/lkml/[email protected]/
>
> Signed-off-by: Sargun Dhillon <[email protected]>
> Cc: Kees Cook <[email protected]>
Looks good.
Reviewed-by: Aleksa Sarai <[email protected]>
> ---
> kernel/seccomp.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 12d2227e5786..4fd73cbdd01e 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -1026,6 +1026,12 @@ static long seccomp_notify_recv(struct seccomp_filter *filter,
> struct seccomp_notif unotif;
> ssize_t ret;
>
> + ret = check_zeroed_user(buf, sizeof(unotif));
> + if (ret < 0)
> + return ret;
> + if (!ret)
> + return -EINVAL;
> +
> memset(&unotif, 0, sizeof(unotif));
>
> ret = down_interruptible(&filter->notif->request);
> --
> 2.20.1
>
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>
On Sat, Dec 28, 2019 at 01:48:51AM +0000, Sargun Dhillon wrote:
> This patch is a small change in enforcement of the uapi for
> SECCOMP_IOCTL_NOTIF_RECV ioctl. Specifically, the datastructure which
> is passed (seccomp_notif) must be zeroed out. Previously any of its
> members could be set to nonsense values, and we would ignore it.
>
> This ensures all fields are set to their zero value.
>
> This relies on the seccomp_notif datastructure to not have
> any unnamed padding, as it is valid to initialize the datastructure
> as:
>
> struct seccomp_notif notif = {};
>
> This only initializes named members to their 0-value [1].
>
> [1]: https://lore.kernel.org/lkml/[email protected]/
>
> Signed-off-by: Sargun Dhillon <[email protected]>
Acked-by: Tycho Andersen <[email protected]>
On Sat, Dec 28, 2019 at 01:48:51AM +0000, Sargun Dhillon wrote:
> This patch is a small change in enforcement of the uapi for
> SECCOMP_IOCTL_NOTIF_RECV ioctl. Specifically, the datastructure which
> is passed (seccomp_notif) must be zeroed out. Previously any of its
> members could be set to nonsense values, and we would ignore it.
>
> This ensures all fields are set to their zero value.
The upper part is correct and useful.
>
> This relies on the seccomp_notif datastructure to not have
> any unnamed padding, as it is valid to initialize the datastructure
> as:
>
> struct seccomp_notif notif = {};
The interesting part here is accidently leaking kernel addresses to
userspace. For this to be an issue we'd need to do
struct seccomp_notif unotif = {};
copy_to_user(<user-buffer>, &unotif, sizeof(unotif))
_and_ seccomp_notif would need to contain unintentional padding. Even if
the latter were true we still use memset() anwyay and will likely never
remove it. So the code here sure doesn't rely or depends on correct
padding at all.
>
> This only initializes named members to their 0-value [1].
>
> [1]: https://lore.kernel.org/lkml/[email protected]/
That link isn't useful and also incorrectly claims that there is
non-intentional padding in the struct which there isn't.
Just drop that whole paragraph. The expectation is that all of our ABIs
are correctly padded anyway and this really just confuses more than it
helps.
Please resend, otherwise:
Reviewed-by: Christian Brauner <[email protected]>
But see a small comment below.
>
> Signed-off-by: Sargun Dhillon <[email protected]>
> Cc: Kees Cook <[email protected]>
> ---
> kernel/seccomp.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 12d2227e5786..4fd73cbdd01e 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -1026,6 +1026,12 @@ static long seccomp_notify_recv(struct seccomp_filter *filter,
> struct seccomp_notif unotif;
> ssize_t ret;
>
> + ret = check_zeroed_user(buf, sizeof(unotif));
It wouldn't hurt to place a small comment here so the reader can easily
spot we've ensured that this struct can be extended. But up to you...
/* Verify that we're not given garbage to keep struct extensible. */
> + if (ret < 0)
> + return ret;
> + if (!ret)
> + return -EINVAL;
> +
> memset(&unotif, 0, sizeof(unotif));
>
> ret = down_interruptible(&filter->notif->request);
> --
> 2.20.1
>