April 2022 - Linux-stable-mirror

FAILED: patch "[PATCH] exec: Force single empty string when argv is empty" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From dcd46d897adb70d63e025f175a00a89797d31a43 Mon Sep 17 00:00:00 2001 From: Kees Cook <keescook(a)chromium.org> Date: Mon, 31 Jan 2022 16:09:47 -0800 Subject: [PATCH] exec: Force single empty string when argv is empty Quoting[1] Ariadne Conill: "In several other operating systems, it is a hard requirement that the second argument to execve(2) be the name of a program, thus prohibiting a scenario where argc < 1. POSIX 2017 also recommends this behaviour, but it is not an explicit requirement[2]: The argument arg0 should point to a filename string that is associated with the process being started by one of the exec functions. ... Interestingly, Michael Kerrisk opened an issue about this in 2008[3], but there was no consensus to support fixing this issue then. Hopefully now that CVE-2021-4034 shows practical exploitative use[4] of this bug in a shellcode, we can reconsider. This issue is being tracked in the KSPP issue tracker[5]." While the initial code searches[6][7] turned up what appeared to be mostly corner case tests, trying to that just reject argv == NULL (or an immediately terminated pointer list) quickly started tripping[8] existing userspace programs. The next best approach is forcing a single empty string into argv and adjusting argc to match. The number of programs depending on argc == 0 seems a smaller set than those calling execve with a NULL argv. Account for the additional stack space in bprm_stack_limits(). Inject an empty string when argc == 0 (and set argc = 1). Warn about the case so userspace has some notice about the change: process './argc0' launched './argc0' with NULL argv: empty string added Additionally WARN() and reject NULL argv usage for kernel threads. [1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.or… [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html [3] https://bugzilla.kernel.org/show_bug.cgi?id=8408 [4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt [5] https://github.com/KSPP/linux/issues/176 [6] https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+… [7] https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%… [8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/ Reported-by: Ariadne Conill <ariadne(a)dereferenced.org> Reported-by: Michael Kerrisk <mtk.manpages(a)gmail.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Rich Felker <dalias(a)libc.org> Cc: Eric Biederman <ebiederm(a)xmission.com> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: linux-fsdevel(a)vger.kernel.org Cc: stable(a)vger.kernel.org Signed-off-by: Kees Cook <keescook(a)chromium.org> Acked-by: Christian Brauner <brauner(a)kernel.org> Acked-by: Ariadne Conill <ariadne(a)dereferenced.org> Acked-by: Andy Lutomirski <luto(a)kernel.org> Link: https://lore.kernel.org/r/20220201000947.2453721-1-keescook@chromium.org diff --git a/fs/exec.c b/fs/exec.c index 79f2c9483302..40b1008fb0f7 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -495,8 +495,14 @@ static int bprm_stack_limits(struct linux_binprm *bprm) * the stack. They aren't stored until much later when we can't * signal to the parent that the child has run out of stack space. * Instead, calculate it here so it's possible to fail gracefully. + * + * In the case of argc = 0, make sure there is space for adding a + * empty string (which will bump argc to 1), to ensure confused + * userspace programs don't start processing from argv[1], thinking + * argc can never be 0, to keep them from walking envp by accident. + * See do_execveat_common(). */ - ptr_size = (bprm->argc + bprm->envc) * sizeof(void *); + ptr_size = (max(bprm->argc, 1) + bprm->envc) * sizeof(void *); if (limit <= ptr_size) return -E2BIG; limit -= ptr_size; @@ -1897,6 +1903,9 @@ static int do_execveat_common(int fd, struct filename *filename, } retval = count(argv, MAX_ARG_STRINGS); + if (retval == 0) + pr_warn_once("process '%s' launched '%s' with NULL argv: empty string added\n", + current->comm, bprm->filename); if (retval < 0) goto out_free; bprm->argc = retval; @@ -1923,6 +1932,19 @@ static int do_execveat_common(int fd, struct filename *filename, if (retval < 0) goto out_free; + /* + * When argv is empty, add an empty string ("") as argv[0] to + * ensure confused userspace programs that start processing + * from argv[1] won't end up walking envp. See also + * bprm_stack_limits(). + */ + if (bprm->argc == 0) { + retval = copy_string_kernel("", bprm); + if (retval < 0) + goto out_free; + bprm->argc = 1; + } + retval = bprm_execve(bprm, fd, filename, flags); out_free: free_bprm(bprm); @@ -1951,6 +1973,8 @@ int kernel_execve(const char *kernel_filename, } retval = count_strings_kernel(argv); + if (WARN_ON_ONCE(retval == 0)) + retval = -EINVAL; if (retval < 0) goto out_free; bprm->argc = retval;

1 year, 3 months

3
2
0 0

[PATCH 4.19 00/20] 4.19.237-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.19.237 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun, 27 Mar 2022 15:04:08 +0000. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.237-r… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 4.19.237-rc1 Arnd Bergmann <arnd(a)arndb.de> nds32: fix access_ok() checks in get/put_user Linus Lüssing <ll(a)simonwunderlich.de> mac80211: fix potential double free on mesh join Giovanni Cabiddu <giovanni.cabiddu(a)intel.com> crypto: qat - disable registration of algorithms Werner Sembach <wse(a)tuxedocomputers.com> ACPI: video: Force backlight native for Clevo NL5xRU and NL5xNU Maximilian Luz <luzmaximilian(a)gmail.com> ACPI: battery: Add device HID and quirk for Microsoft Surface Go 3 Mark Cilissen <mark(a)yotsuba.nl> ACPI / x86: Work around broken XSDT on Advantech DAC-BJ01 board Pablo Neira Ayuso <pablo(a)netfilter.org> netfilter: nf_tables: initialize registers in nft_do_chain() Stephane Graber <stgraber(a)ubuntu.com> drivers: net: xgene: Fix regression in CRC stripping Giacomo Guiduzzi <guiduzzi.giacomo(a)gmail.com> ALSA: pci: fix reading of swapped values from pcmreg in AC97 codec Jonathan Teh <jonathan.teh(a)outlook.com> ALSA: cmipci: Restore aux vol on suspend/resume Lars-Peter Clausen <lars(a)metafoo.de> ALSA: usb-audio: Add mute TLV for playback volumes on RODE NT-USB Takashi Iwai <tiwai(a)suse.de> ALSA: pcm: Add stream lock during PCM reset ioctl operations Takashi Iwai <tiwai(a)suse.de> ALSA: oss: Fix PCM OSS buffer allocation overflow Takashi Iwai <tiwai(a)suse.de> ASoC: sti: Fix deadlock via snd_pcm_stop_xrun() call Eric Dumazet <edumazet(a)google.com> llc: fix netdevice reference leaks in llc_ui_bind() Chuansheng Liu <chuansheng.liu(a)intel.com> thermal: int340x: fix memory leak in int3400_notify() Oliver Graute <oliver.graute(a)kococonnector.com> staging: fbtft: fb_st7789v: reset display before initialization Steffen Klassert <steffen.klassert(a)secunet.com> esp: Fix possible buffer overflow in ESP transformation Tadeusz Struk <tadeusz.struk(a)linaro.org> net: ipv6: fix skb_over_panic in __ip6_append_data Jordy Zomer <jordy(a)pwning.systems> nfc: st21nfca: Fix potential buffer overflows in EVT_TRANSACTION ------------- Diffstat: Makefile | 4 +- arch/nds32/include/asm/uaccess.h | 22 +++++-- arch/x86/kernel/acpi/boot.c | 24 ++++++++ drivers/acpi/battery.c | 12 ++++ drivers/acpi/video_detect.c | 75 +++++++++++++++++++++++ drivers/crypto/qat/qat_common/qat_crypto.c | 8 +++ drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 12 ++-- drivers/nfc/st21nfca/se.c | 10 +++ drivers/staging/fbtft/fb_st7789v.c | 2 + drivers/thermal/int340x_thermal/int3400_thermal.c | 4 ++ include/net/esp.h | 2 + include/net/sock.h | 3 + net/core/sock.c | 3 - net/ipv4/esp4.c | 5 ++ net/ipv6/esp6.c | 5 ++ net/ipv6/ip6_output.c | 4 +- net/llc/af_llc.c | 8 +++ net/mac80211/cfg.c | 3 - net/netfilter/nf_tables_core.c | 2 +- sound/core/oss/pcm_oss.c | 12 ++-- sound/core/oss/pcm_plugin.c | 5 +- sound/core/pcm_native.c | 4 ++ sound/pci/ac97/ac97_codec.c | 4 +- sound/pci/cmipci.c | 3 +- sound/soc/sti/uniperif_player.c | 6 +- sound/soc/sti/uniperif_reader.c | 2 +- sound/usb/mixer_quirks.c | 7 ++- 27 files changed, 214 insertions(+), 37 deletions(-)

1 year, 3 months

10
30
0 0

[PATCH] bpf: Fix KASAN use-after-free Read in compute_effective_progs

by Tadeusz Struk

Syzbot found a Use After Free bug in compute_effective_progs(). The reproducer creates a number of BPF links, and causes a fault injected alloc to fail, while calling bpf_link_detach on them. Link detach triggers the link to be freed by bpf_link_free(), which calls __cgroup_bpf_detach() and update_effective_progs(). If the memory allocation in this function fails, the function restores the pointer to the bpf_cgroup_link on the cgroup list, but the memory gets freed just after it returns. After this, every subsequent call to update_effective_progs() causes this already deallocated pointer to be dereferenced in prog_list_length(), and triggers KASAN UAF error. To fix this don't preserve the pointer to the link on the cgroup list in __cgroup_bpf_detach(), but proceed with the cleanup and retry calling update_effective_progs() again afterwards. Cc: "Alexei Starovoitov" <ast(a)kernel.org> Cc: "Daniel Borkmann" <daniel(a)iogearbox.net> Cc: "Andrii Nakryiko" <andrii(a)kernel.org> Cc: "Martin KaFai Lau" <kafai(a)fb.com> Cc: "Song Liu" <songliubraving(a)fb.com> Cc: "Yonghong Song" <yhs(a)fb.com> Cc: "John Fastabend" <john.fastabend(a)gmail.com> Cc: "KP Singh" <kpsingh(a)kernel.org> Cc: <netdev(a)vger.kernel.org> Cc: <bpf(a)vger.kernel.org> Cc: <stable(a)vger.kernel.org> Cc: <linux-kernel(a)vger.kernel.org> Link: https://syzkaller.appspot.com/bug?id=8ebf179a95c2a2670f7cf1ba62429ec044369d… Fixes: af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment") Reported-by: <syzbot+f264bffdfbd5614f3bb2(a)syzkaller.appspotmail.com> Signed-off-by: Tadeusz Struk <tadeusz.struk(a)linaro.org> --- kernel/bpf/cgroup.c | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c index 128028efda64..b6307337a3c7 100644 --- a/kernel/bpf/cgroup.c +++ b/kernel/bpf/cgroup.c @@ -723,10 +723,11 @@ static int __cgroup_bpf_detach(struct cgroup *cgrp, struct bpf_prog *prog, pl->link = NULL; err = update_effective_progs(cgrp, atype); - if (err) - goto cleanup; - - /* now can actually delete it from this cgroup list */ + /* + * Proceed regardless of error. The link and/or prog will be freed + * just after this function returns so just delete it from this + * cgroup list and retry calling update_effective_progs again later. + */ list_del(&pl->node); kfree(pl); if (list_empty(progs)) @@ -735,12 +736,11 @@ static int __cgroup_bpf_detach(struct cgroup *cgrp, struct bpf_prog *prog, if (old_prog) bpf_prog_put(old_prog); static_branch_dec(&cgroup_bpf_enabled_key[atype]); - return 0; -cleanup: - /* restore back prog or link */ - pl->prog = old_prog; - pl->link = link; + /* In case of error call update_effective_progs again */ + if (err) + err = update_effective_progs(cgrp, atype); + return err; } @@ -881,6 +881,7 @@ static void bpf_cgroup_link_release(struct bpf_link *link) struct bpf_cgroup_link *cg_link = container_of(link, struct bpf_cgroup_link, link); struct cgroup *cg; + int err; /* link might have been auto-detached by dying cgroup already, * in that case our work is done here @@ -896,8 +897,10 @@ static void bpf_cgroup_link_release(struct bpf_link *link) return; } - WARN_ON(__cgroup_bpf_detach(cg_link->cgroup, NULL, cg_link, - cg_link->type)); + err = __cgroup_bpf_detach(cg_link->cgroup, NULL, cg_link, + cg_link->type); + if (err) + pr_warn("cgroup_bpf_detach() failed, err %d\n", err); cg = cg_link->cgroup; cg_link->cgroup = NULL; -- 2.35.1

1 year, 3 months

2
21
0 0

FAILED: patch "[PATCH] exec: Force single empty string when argv is empty" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From dcd46d897adb70d63e025f175a00a89797d31a43 Mon Sep 17 00:00:00 2001 From: Kees Cook <keescook(a)chromium.org> Date: Mon, 31 Jan 2022 16:09:47 -0800 Subject: [PATCH] exec: Force single empty string when argv is empty Quoting[1] Ariadne Conill: "In several other operating systems, it is a hard requirement that the second argument to execve(2) be the name of a program, thus prohibiting a scenario where argc < 1. POSIX 2017 also recommends this behaviour, but it is not an explicit requirement[2]: The argument arg0 should point to a filename string that is associated with the process being started by one of the exec functions. ... Interestingly, Michael Kerrisk opened an issue about this in 2008[3], but there was no consensus to support fixing this issue then. Hopefully now that CVE-2021-4034 shows practical exploitative use[4] of this bug in a shellcode, we can reconsider. This issue is being tracked in the KSPP issue tracker[5]." While the initial code searches[6][7] turned up what appeared to be mostly corner case tests, trying to that just reject argv == NULL (or an immediately terminated pointer list) quickly started tripping[8] existing userspace programs. The next best approach is forcing a single empty string into argv and adjusting argc to match. The number of programs depending on argc == 0 seems a smaller set than those calling execve with a NULL argv. Account for the additional stack space in bprm_stack_limits(). Inject an empty string when argc == 0 (and set argc = 1). Warn about the case so userspace has some notice about the change: process './argc0' launched './argc0' with NULL argv: empty string added Additionally WARN() and reject NULL argv usage for kernel threads. [1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.or… [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html [3] https://bugzilla.kernel.org/show_bug.cgi?id=8408 [4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt [5] https://github.com/KSPP/linux/issues/176 [6] https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+… [7] https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%… [8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/ Reported-by: Ariadne Conill <ariadne(a)dereferenced.org> Reported-by: Michael Kerrisk <mtk.manpages(a)gmail.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Rich Felker <dalias(a)libc.org> Cc: Eric Biederman <ebiederm(a)xmission.com> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: linux-fsdevel(a)vger.kernel.org Cc: stable(a)vger.kernel.org Signed-off-by: Kees Cook <keescook(a)chromium.org> Acked-by: Christian Brauner <brauner(a)kernel.org> Acked-by: Ariadne Conill <ariadne(a)dereferenced.org> Acked-by: Andy Lutomirski <luto(a)kernel.org> Link: https://lore.kernel.org/r/20220201000947.2453721-1-keescook@chromium.org diff --git a/fs/exec.c b/fs/exec.c index 79f2c9483302..40b1008fb0f7 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -495,8 +495,14 @@ static int bprm_stack_limits(struct linux_binprm *bprm) * the stack. They aren't stored until much later when we can't * signal to the parent that the child has run out of stack space. * Instead, calculate it here so it's possible to fail gracefully. + * + * In the case of argc = 0, make sure there is space for adding a + * empty string (which will bump argc to 1), to ensure confused + * userspace programs don't start processing from argv[1], thinking + * argc can never be 0, to keep them from walking envp by accident. + * See do_execveat_common(). */ - ptr_size = (bprm->argc + bprm->envc) * sizeof(void *); + ptr_size = (max(bprm->argc, 1) + bprm->envc) * sizeof(void *); if (limit <= ptr_size) return -E2BIG; limit -= ptr_size; @@ -1897,6 +1903,9 @@ static int do_execveat_common(int fd, struct filename *filename, } retval = count(argv, MAX_ARG_STRINGS); + if (retval == 0) + pr_warn_once("process '%s' launched '%s' with NULL argv: empty string added\n", + current->comm, bprm->filename); if (retval < 0) goto out_free; bprm->argc = retval; @@ -1923,6 +1932,19 @@ static int do_execveat_common(int fd, struct filename *filename, if (retval < 0) goto out_free; + /* + * When argv is empty, add an empty string ("") as argv[0] to + * ensure confused userspace programs that start processing + * from argv[1] won't end up walking envp. See also + * bprm_stack_limits(). + */ + if (bprm->argc == 0) { + retval = copy_string_kernel("", bprm); + if (retval < 0) + goto out_free; + bprm->argc = 1; + } + retval = bprm_execve(bprm, fd, filename, flags); out_free: free_bprm(bprm); @@ -1951,6 +1973,8 @@ int kernel_execve(const char *kernel_filename, } retval = count_strings_kernel(argv); + if (WARN_ON_ONCE(retval == 0)) + retval = -EINVAL; if (retval < 0) goto out_free; bprm->argc = retval;

1 year, 3 months

2
1
0 0

FAILED: patch "[PATCH] exec: Force single empty string when argv is empty" failed to apply to 4.19-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.19-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From dcd46d897adb70d63e025f175a00a89797d31a43 Mon Sep 17 00:00:00 2001 From: Kees Cook <keescook(a)chromium.org> Date: Mon, 31 Jan 2022 16:09:47 -0800 Subject: [PATCH] exec: Force single empty string when argv is empty Quoting[1] Ariadne Conill: "In several other operating systems, it is a hard requirement that the second argument to execve(2) be the name of a program, thus prohibiting a scenario where argc < 1. POSIX 2017 also recommends this behaviour, but it is not an explicit requirement[2]: The argument arg0 should point to a filename string that is associated with the process being started by one of the exec functions. ... Interestingly, Michael Kerrisk opened an issue about this in 2008[3], but there was no consensus to support fixing this issue then. Hopefully now that CVE-2021-4034 shows practical exploitative use[4] of this bug in a shellcode, we can reconsider. This issue is being tracked in the KSPP issue tracker[5]." While the initial code searches[6][7] turned up what appeared to be mostly corner case tests, trying to that just reject argv == NULL (or an immediately terminated pointer list) quickly started tripping[8] existing userspace programs. The next best approach is forcing a single empty string into argv and adjusting argc to match. The number of programs depending on argc == 0 seems a smaller set than those calling execve with a NULL argv. Account for the additional stack space in bprm_stack_limits(). Inject an empty string when argc == 0 (and set argc = 1). Warn about the case so userspace has some notice about the change: process './argc0' launched './argc0' with NULL argv: empty string added Additionally WARN() and reject NULL argv usage for kernel threads. [1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.or… [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html [3] https://bugzilla.kernel.org/show_bug.cgi?id=8408 [4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt [5] https://github.com/KSPP/linux/issues/176 [6] https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+… [7] https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%… [8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/ Reported-by: Ariadne Conill <ariadne(a)dereferenced.org> Reported-by: Michael Kerrisk <mtk.manpages(a)gmail.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Rich Felker <dalias(a)libc.org> Cc: Eric Biederman <ebiederm(a)xmission.com> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: linux-fsdevel(a)vger.kernel.org Cc: stable(a)vger.kernel.org Signed-off-by: Kees Cook <keescook(a)chromium.org> Acked-by: Christian Brauner <brauner(a)kernel.org> Acked-by: Ariadne Conill <ariadne(a)dereferenced.org> Acked-by: Andy Lutomirski <luto(a)kernel.org> Link: https://lore.kernel.org/r/20220201000947.2453721-1-keescook@chromium.org diff --git a/fs/exec.c b/fs/exec.c index 79f2c9483302..40b1008fb0f7 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -495,8 +495,14 @@ static int bprm_stack_limits(struct linux_binprm *bprm) * the stack. They aren't stored until much later when we can't * signal to the parent that the child has run out of stack space. * Instead, calculate it here so it's possible to fail gracefully. + * + * In the case of argc = 0, make sure there is space for adding a + * empty string (which will bump argc to 1), to ensure confused + * userspace programs don't start processing from argv[1], thinking + * argc can never be 0, to keep them from walking envp by accident. + * See do_execveat_common(). */ - ptr_size = (bprm->argc + bprm->envc) * sizeof(void *); + ptr_size = (max(bprm->argc, 1) + bprm->envc) * sizeof(void *); if (limit <= ptr_size) return -E2BIG; limit -= ptr_size; @@ -1897,6 +1903,9 @@ static int do_execveat_common(int fd, struct filename *filename, } retval = count(argv, MAX_ARG_STRINGS); + if (retval == 0) + pr_warn_once("process '%s' launched '%s' with NULL argv: empty string added\n", + current->comm, bprm->filename); if (retval < 0) goto out_free; bprm->argc = retval; @@ -1923,6 +1932,19 @@ static int do_execveat_common(int fd, struct filename *filename, if (retval < 0) goto out_free; + /* + * When argv is empty, add an empty string ("") as argv[0] to + * ensure confused userspace programs that start processing + * from argv[1] won't end up walking envp. See also + * bprm_stack_limits(). + */ + if (bprm->argc == 0) { + retval = copy_string_kernel("", bprm); + if (retval < 0) + goto out_free; + bprm->argc = 1; + } + retval = bprm_execve(bprm, fd, filename, flags); out_free: free_bprm(bprm); @@ -1951,6 +1973,8 @@ int kernel_execve(const char *kernel_filename, } retval = count_strings_kernel(argv); + if (WARN_ON_ONCE(retval == 0)) + retval = -EINVAL; if (retval < 0) goto out_free; bprm->argc = retval;

1 year, 3 months

2
1
0 0

FAILED: patch "[PATCH] exec: Force single empty string when argv is empty" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From dcd46d897adb70d63e025f175a00a89797d31a43 Mon Sep 17 00:00:00 2001 From: Kees Cook <keescook(a)chromium.org> Date: Mon, 31 Jan 2022 16:09:47 -0800 Subject: [PATCH] exec: Force single empty string when argv is empty Quoting[1] Ariadne Conill: "In several other operating systems, it is a hard requirement that the second argument to execve(2) be the name of a program, thus prohibiting a scenario where argc < 1. POSIX 2017 also recommends this behaviour, but it is not an explicit requirement[2]: The argument arg0 should point to a filename string that is associated with the process being started by one of the exec functions. ... Interestingly, Michael Kerrisk opened an issue about this in 2008[3], but there was no consensus to support fixing this issue then. Hopefully now that CVE-2021-4034 shows practical exploitative use[4] of this bug in a shellcode, we can reconsider. This issue is being tracked in the KSPP issue tracker[5]." While the initial code searches[6][7] turned up what appeared to be mostly corner case tests, trying to that just reject argv == NULL (or an immediately terminated pointer list) quickly started tripping[8] existing userspace programs. The next best approach is forcing a single empty string into argv and adjusting argc to match. The number of programs depending on argc == 0 seems a smaller set than those calling execve with a NULL argv. Account for the additional stack space in bprm_stack_limits(). Inject an empty string when argc == 0 (and set argc = 1). Warn about the case so userspace has some notice about the change: process './argc0' launched './argc0' with NULL argv: empty string added Additionally WARN() and reject NULL argv usage for kernel threads. [1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.or… [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html [3] https://bugzilla.kernel.org/show_bug.cgi?id=8408 [4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt [5] https://github.com/KSPP/linux/issues/176 [6] https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+… [7] https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%… [8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/ Reported-by: Ariadne Conill <ariadne(a)dereferenced.org> Reported-by: Michael Kerrisk <mtk.manpages(a)gmail.com> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Rich Felker <dalias(a)libc.org> Cc: Eric Biederman <ebiederm(a)xmission.com> Cc: Alexander Viro <viro(a)zeniv.linux.org.uk> Cc: linux-fsdevel(a)vger.kernel.org Cc: stable(a)vger.kernel.org Signed-off-by: Kees Cook <keescook(a)chromium.org> Acked-by: Christian Brauner <brauner(a)kernel.org> Acked-by: Ariadne Conill <ariadne(a)dereferenced.org> Acked-by: Andy Lutomirski <luto(a)kernel.org> Link: https://lore.kernel.org/r/20220201000947.2453721-1-keescook@chromium.org diff --git a/fs/exec.c b/fs/exec.c index 79f2c9483302..40b1008fb0f7 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -495,8 +495,14 @@ static int bprm_stack_limits(struct linux_binprm *bprm) * the stack. They aren't stored until much later when we can't * signal to the parent that the child has run out of stack space. * Instead, calculate it here so it's possible to fail gracefully. + * + * In the case of argc = 0, make sure there is space for adding a + * empty string (which will bump argc to 1), to ensure confused + * userspace programs don't start processing from argv[1], thinking + * argc can never be 0, to keep them from walking envp by accident. + * See do_execveat_common(). */ - ptr_size = (bprm->argc + bprm->envc) * sizeof(void *); + ptr_size = (max(bprm->argc, 1) + bprm->envc) * sizeof(void *); if (limit <= ptr_size) return -E2BIG; limit -= ptr_size; @@ -1897,6 +1903,9 @@ static int do_execveat_common(int fd, struct filename *filename, } retval = count(argv, MAX_ARG_STRINGS); + if (retval == 0) + pr_warn_once("process '%s' launched '%s' with NULL argv: empty string added\n", + current->comm, bprm->filename); if (retval < 0) goto out_free; bprm->argc = retval; @@ -1923,6 +1932,19 @@ static int do_execveat_common(int fd, struct filename *filename, if (retval < 0) goto out_free; + /* + * When argv is empty, add an empty string ("") as argv[0] to + * ensure confused userspace programs that start processing + * from argv[1] won't end up walking envp. See also + * bprm_stack_limits(). + */ + if (bprm->argc == 0) { + retval = copy_string_kernel("", bprm); + if (retval < 0) + goto out_free; + bprm->argc = 1; + } + retval = bprm_execve(bprm, fd, filename, flags); out_free: free_bprm(bprm); @@ -1951,6 +1973,8 @@ int kernel_execve(const char *kernel_filename, } retval = count_strings_kernel(argv); + if (WARN_ON_ONCE(retval == 0)) + retval = -EINVAL; if (retval < 0) goto out_free; bprm->argc = retval;

1 year, 3 months

2
1
0 0

[RESEND][PATCH] KVM: PPC: Book3S HV: fix incorrect NULL check on list iterator

by Xiaomeng Tong

The bug is here: if (!p) return ret; The list iterator value 'p' will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found. To fix the bug, Use a new value 'iter' as the list iterator, while use the old value 'p' as a dedicated variable to point to the found element. Cc: stable(a)vger.kernel.org Fixes: dfaa973ae9605 ("KVM: PPC: Book3S HV: In H_SVM_INIT_DONE, migrate remaining normal-GFNs to secure-GFNs") Signed-off-by: Xiaomeng Tong <xiam0nd.tong(a)gmail.com> --- arch/powerpc/kvm/book3s_hv_uvmem.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c index e414ca44839f..0cb20ee6a632 100644 --- a/arch/powerpc/kvm/book3s_hv_uvmem.c +++ b/arch/powerpc/kvm/book3s_hv_uvmem.c @@ -360,13 +360,15 @@ static bool kvmppc_gfn_is_uvmem_pfn(unsigned long gfn, struct kvm *kvm, static bool kvmppc_next_nontransitioned_gfn(const struct kvm_memory_slot *memslot, struct kvm *kvm, unsigned long *gfn) { - struct kvmppc_uvmem_slot *p; + struct kvmppc_uvmem_slot *p = NULL, *iter; bool ret = false; unsigned long i; - list_for_each_entry(p, &kvm->arch.uvmem_pfns, list) - if (*gfn >= p->base_pfn && *gfn < p->base_pfn + p->nr_pfns) + list_for_each_entry(iter, &kvm->arch.uvmem_pfns, list) + if (*gfn >= iter->base_pfn && *gfn < iter->base_pfn + iter->nr_pfns) { + p = iter; break; + } if (!p) return ret; /* -- 2.17.1

1 year, 4 months

2
1
0 0

[PATCH] cgroup: don't queue css_release_work if one already pending

by Tadeusz Struk

Syzbot found a corrupted list bug scenario that can be triggered from cgroup css_create(). The reproduces writes to cgroup.subtree_control file, which invokes cgroup_apply_control_enable(), css_create(), and css_populate_dir(), which then randomly fails with a fault injected -ENOMEM. In such scenario the css_create() error path rcu enqueues css_free_rwork_fn work for an css->refcnt initialized with css_release() destructor, and there is a chance that the css_release() function will be invoked for a cgroup_subsys_state, for which a destroy_work has already been queued via css_create() error path. This causes a list_add corruption as can be seen in the syzkaller report [1]. This can be avoided by adding a check to css_release() that checks if it has already been enqueued. [1] https://syzkaller.appspot.com/bug?id=e26e54d6eac9d9fb50b221ec3e4627b327465d… Cc: Tejun Heo <tj(a)kernel.org> Cc: Zefan Li <lizefan.x(a)bytedance.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Alexei Starovoitov <ast(a)kernel.org> Cc: Daniel Borkmann <daniel(a)iogearbox.net> Cc: Andrii Nakryiko <andrii(a)kernel.org> Cc: Martin KaFai Lau <kafai(a)fb.com> Cc: Song Liu <songliubraving(a)fb.com> Cc: Yonghong Song <yhs(a)fb.com> Cc: John Fastabend <john.fastabend(a)gmail.com> Cc: KP Singh <kpsingh(a)kernel.org> Cc: <cgroups(a)vger.kernel.org> Cc: <netdev(a)vger.kernel.org> Cc: <bpf(a)vger.kernel.org> Cc: <stable(a)vger.kernel.org> Cc: <linux-kernel(a)vger.kernel.org> Reported-by: syzbot+e42ae441c3b10acf9e9d(a)syzkaller.appspotmail.com Fixes: 8f36aaec9c92 ("cgroup: Use rcu_work instead of explicit rcu and work item") Signed-off-by: Tadeusz Struk <tadeusz.struk(a)linaro.org> --- kernel/cgroup/cgroup.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c index adb820e98f24..9ae2de29f8c9 100644 --- a/kernel/cgroup/cgroup.c +++ b/kernel/cgroup/cgroup.c @@ -5210,8 +5210,11 @@ static void css_release(struct percpu_ref *ref) struct cgroup_subsys_state *css = container_of(ref, struct cgroup_subsys_state, refcnt); - INIT_WORK(&css->destroy_work, css_release_work_fn); - queue_work(cgroup_destroy_wq, &css->destroy_work); + if (!test_and_set_bit(WORK_STRUCT_PENDING_BIT, + work_data_bits(&css->destroy_work))) { + INIT_WORK(&css->destroy_work, css_release_work_fn); + queue_work(cgroup_destroy_wq, &css->destroy_work); + } } static void init_and_link_css(struct cgroup_subsys_state *css, -- 2.35.1

1 year, 4 months

3
7
0 0

[PATCH] drm/bridge: fix anx6345 power up sequence

by Torsten Duwe

Align the power-up sequence with the known-good procedure documented in [1]: un-swap dvdd12 and dvdd25, and allow a little extra time for them to settle before de-asserting reset. Fixes: 6aa192698089b ("drm/bridge: Add Analogix anx6345 support") [1] https://github.com/OLIMEX/DIY-LAPTOP/blob/master/ HARDWARE/A64-TERES/TERES-PCB1-A64-MAIN/Rev.C/TERES_PCB1-A64-MAIN_Rev.C.pdf (page 5, blue comment down left) Reported-by: Harald Geyer <harald(a)ccbib.org> Signed-off-by: Torsten Duwe <duwe(a)lst.de> Cc: stable(a)vger.kernel.org --- This fixes the problem that e.g. X screensaver turns the screen black, and it stays black until the next reboot; definitely on the Teres-I, probably on the pinebook64, too. --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c @@ -309,27 +309,27 @@ static void anx6345_poweron(struct anx63 gpiod_set_value_cansleep(anx6345->gpiod_reset, 1); usleep_range(1000, 2000); - err = regulator_enable(anx6345->dvdd12); + err = regulator_enable(anx6345->dvdd25); if (err) { - DRM_ERROR("Failed to enable dvdd12 regulator: %d\n", + DRM_ERROR("Failed to enable dvdd25 regulator: %d\n", err); return; } - /* T1 - delay between VDD12 and VDD25 should be 0-2ms */ + /* T1 - delay between VDD25 and VDD12 should be 0-2ms */ usleep_range(1000, 2000); - err = regulator_enable(anx6345->dvdd25); + err = regulator_enable(anx6345->dvdd12); if (err) { - DRM_ERROR("Failed to enable dvdd25 regulator: %d\n", + DRM_ERROR("Failed to enable dvdd12 regulator: %d\n", err); return; } /* T2 - delay between RESETN and all power rail stable, - * should be 2-5ms + * should be at least 2-5ms, 10ms to be safe. */ - usleep_range(2000, 5000); + usleep_range(9000, 11000); gpiod_set_value_cansleep(anx6345->gpiod_reset, 0);

1 year, 4 months

2
6
0 0

[PATCH 1/2] x86/mpparse: avoid overwriting boot_cpu_physical_apicid

by Kevin Mitchell

When booting with ACPI unavailable or disabled, get_smp_config() ends up calling MP_processor_info() for each CPU found in the MPS table. Previously, this resulted in boot_cpu_physical_apicid getting unconditionally overwritten by the apicid of whatever processor had the CPU_BOOTPROCESSOR flag. This occurred even if boot_cpu_physical_apicid had already been more reliably determined in register_lapic_address() by calling read_apic_id() from the actual boot processor. Ordinariliy, this is not a problem because the boot processor really is the one with the CPU_BOOTPROCESSOR flag. However, kexec is an exception in which the kernel may be booted from any processor regardless of the MPS table contents. In this case, boot_cpu_physical_apicid may not indicate the actual boot processor. This was particularly problematic when the second kernel was booted with NR_CPUS fewer than the number of physical processors. It's the job of generic_processor_info() to decide which CPUs to bring up in this case. That obviously must include the real boot processor which it takes care to save a slot for. It relies upon the contents of boot_cpu_physical_apicid to do this, which if incorrect, may result in the boot processor getting left out. This condition can be discovered by smp_sanity_check() and rectified by adding the boot processor to the phys_cpu_present_map with the warning "weird, boot CPU (#%d) not listed by the BIOS". However, commit 3e730dad3b6da ("x86/apic: Unify interrupt mode setup for SMP-capable system") caused setup_local_APIC() to be called before this could happen resulting in a BUG_ON(!apic->apic_id_registered()): [ 0.655452] ------------[ cut here ]------------ [ 0.660610] Kernel BUG at setup_local_APIC+0x74/0x280 [verbose debug info unavailable] [ 0.669466] invalid opcode: 0000 [#1] SMP [ 0.673948] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.109.Ar-16509018.eostrunkkernel419 #1 [ 0.683670] Hardware name: Quanta Quanta LY6 (1LY6UZZ0FBC), BIOS 1.0.6.0-e7d6a55 11/26/2015 [ 0.693007] RIP: 0010:setup_local_APIC+0x74/0x280 [ 0.698264] Code: 80 e4 fe bf f0 00 00 00 89 c6 48 8b 05 0f 1a 8e 00 ff 50 10 e8 12 53 fd ff 48 8b 05 00 1a 8e 00 ff 90 a0 00 00 00 85 c0 75 02 <0f> 0b 48 8b 05 ed 19 8e 00 41 be 00 02 00 00 ff 90 b0 00 00 00 48 [ 0.719251] RSP: 0000:ffffffff81a03e20 EFLAGS: 00010246 [ 0.725091] RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 [ 0.733066] RDX: 0000000000000000 RSI: 000000000000000f RDI: 0000000000000020 [ 0.741041] RBP: ffffffff81a03e98 R08: 0000000000000002 R09: 0000000000000000 [ 0.749014] R10: ffffffff81a204e0 R11: ffffffff81b50ea7 R12: 0000000000000000 [ 0.756989] R13: ffffffff81aef920 R14: ffffffff81af60a0 R15: 0000000000000000 [ 0.764965] FS: 0000000000000000(0000) GS:ffff888036800000(0000) knlGS:0000000000000000 [ 0.774007] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.780427] CR2: ffff888035c01000 CR3: 0000000035a08000 CR4: 00000000000006b0 [ 0.788401] Call Trace: [ 0.791137] ? amd_iommu_prepare+0x15/0x2a [ 0.795717] apic_bsp_setup+0x55/0x75 [ 0.799808] apic_intr_mode_init+0x169/0x16e [ 0.804579] x86_late_time_init+0x10/0x17 [ 0.809062] start_kernel+0x37e/0x3fe [ 0.813154] x86_64_start_reservations+0x2a/0x2c [ 0.818316] x86_64_start_kernel+0x72/0x75 [ 0.822886] secondary_startup_64+0xa4/0xb0 [ 0.827564] ---[ end trace 237b64da0fd9b22e ]--- This change avoids these issues by only setting boot_cpu_physical_apicid from the MPS table if it is not already set, which can occur in the construct_default_ISA_mptable() path. Otherwise, boot_cpu_physical_apicid will already have been set in register_lapic_address() and should therefore remain untouched. Looking through all the places where boot_cpu_physical_apicid is accessed, nearly all of them assume that boot_cpu_physical_apicid should match read_apic_id() on the booting processor. The only place that might intend to use the BSP apicid listed in the MPS table is amd_numa_init(), which explicitly requires boot_cpu_physical_apicid to be the lowest apicid of all processors. Ironically, due to the early exit short circuit in early_get_smp_config(), it instead gets boot_cpu_physical_apicid = read_apic_id() rather than the MPS table BSP. The behaviour of amd_numa_init() is therefore unaffected by this change. Fixes: 3e730dad3b6da ("x86/apic: Unify interrupt mode setup for SMP-capable system") Signed-off-by: Kevin Mitchell <kevmitch(a)arista.com> Cc: <stable(a)vger.kernel.org> --- arch/x86/kernel/mpparse.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c index afac7ccce72f..6f22f09bfe11 100644 --- a/arch/x86/kernel/mpparse.c +++ b/arch/x86/kernel/mpparse.c @@ -64,7 +64,8 @@ static void __init MP_processor_info(struct mpc_cpu *m) if (m->cpuflag & CPU_BOOTPROCESSOR) { bootup_cpu = " (Bootup-CPU)"; - boot_cpu_physical_apicid = m->apicid; + if (boot_cpu_physical_apicid == -1U) + boot_cpu_physical_apicid = m->apicid; } pr_info("Processor #%d%s\n", m->apicid, bootup_cpu); -- 2.26.2

1 year, 4 months

1
1
0 0

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2022