In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields. Wrap the target region
in struct_group(). This additionally fixes a theoretical misalignment
of the copy (since the size of "buf" changes between 64-bit and 32-bit,
but this is likely never built for 64-bit).
FWIW, I think this code is totally broken on 64-bit (which appears to
not be a "real" build configuration): it would either always fail (with
an uninitialized data->buf_size) or would cause corruption in userspace
due to the copy_to_user() in the call path against an uninitialized
data->buf value:
omap3isp_stat_request_statistics_time32(...)
struct omap3isp_stat_data data64;
...
omap3isp_stat_request_statistics(stat, &data64);
int omap3isp_stat_request_statistics(struct ispstat *stat,
struct omap3isp_stat_data *data)
...
buf = isp_stat_buf_get(stat, data);
static struct ispstat_buffer *isp_stat_buf_get(struct ispstat *stat,
struct omap3isp_stat_data *data)
...
if (buf->buf_size > data->buf_size) {
...
return ERR_PTR(-EINVAL);
}
...
rval = copy_to_user(data->buf,
buf->virt_addr,
buf->buf_size);
Regardless, additionally initialize data64 to be zero-filled to avoid
undefined behavior.
Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Cc: linux-media(a)vger.kernel.org
Fixes: 378e3f81cb56 ("media: omap3isp: support 64-bit version of omap3isp_stat_data")
Cc: stable(a)vger.kernel.org
Reviewed-by: Gustavo A. R. Silva <gustavoars(a)kernel.org>
Link: https://lore.kernel.org/lkml/20211215220505.GB21862@embeddedor
Signed-off-by: Kees Cook <keescook(a)chromium.org>
---
I will carry this in my tree unless someone else wants to pick it up. It's
one of the last remaining clean-ups needed for the next step in memcpy()
hardening.
---
drivers/media/platform/omap3isp/ispstat.c | 5 +++--
include/uapi/linux/omap3isp.h | 21 +++++++++++++--------
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispstat.c b/drivers/media/platform/omap3isp/ispstat.c
index 5b9b57f4d9bf..68cf68dbcace 100644
--- a/drivers/media/platform/omap3isp/ispstat.c
+++ b/drivers/media/platform/omap3isp/ispstat.c
@@ -512,7 +512,7 @@ int omap3isp_stat_request_statistics(struct ispstat *stat,
int omap3isp_stat_request_statistics_time32(struct ispstat *stat,
struct omap3isp_stat_data_time32 *data)
{
- struct omap3isp_stat_data data64;
+ struct omap3isp_stat_data data64 = { };
int ret;
ret = omap3isp_stat_request_statistics(stat, &data64);
@@ -521,7 +521,8 @@ int omap3isp_stat_request_statistics_time32(struct ispstat *stat,
data->ts.tv_sec = data64.ts.tv_sec;
data->ts.tv_usec = data64.ts.tv_usec;
- memcpy(&data->buf, &data64.buf, sizeof(*data) - sizeof(data->ts));
+ data->buf = (uintptr_t)data64.buf;
+ memcpy(&data->frame, &data64.frame, sizeof(data->frame));
return 0;
}
diff --git a/include/uapi/linux/omap3isp.h b/include/uapi/linux/omap3isp.h
index 87b55755f4ff..d9db7ad43890 100644
--- a/include/uapi/linux/omap3isp.h
+++ b/include/uapi/linux/omap3isp.h
@@ -162,6 +162,7 @@ struct omap3isp_h3a_aewb_config {
* struct omap3isp_stat_data - Statistic data sent to or received from user
* @ts: Timestamp of returned framestats.
* @buf: Pointer to pass to user.
+ * @buf_size: Size of buffer.
* @frame_number: Frame number of requested stats.
* @cur_frame: Current frame number being processed.
* @config_counter: Number of the configuration associated with the data.
@@ -176,10 +177,12 @@ struct omap3isp_stat_data {
struct timeval ts;
#endif
void __user *buf;
- __u32 buf_size;
- __u16 frame_number;
- __u16 cur_frame;
- __u16 config_counter;
+ __struct_group(/* no tag */, frame, /* no attrs */,
+ __u32 buf_size;
+ __u16 frame_number;
+ __u16 cur_frame;
+ __u16 config_counter;
+ );
};
#ifdef __KERNEL__
@@ -189,10 +192,12 @@ struct omap3isp_stat_data_time32 {
__s32 tv_usec;
} ts;
__u32 buf;
- __u32 buf_size;
- __u16 frame_number;
- __u16 cur_frame;
- __u16 config_counter;
+ __struct_group(/* no tag */, frame, /* no attrs */,
+ __u32 buf_size;
+ __u16 frame_number;
+ __u16 cur_frame;
+ __u16 config_counter;
+ );
};
#endif
--
2.30.2
The patch titled
Subject: mm/pgtable: define pte_index so that preprocessor could recognize it
has been added to the -mm tree. Its filename is
mm-pgtable-define-pte_index-so-that-preprocessor-could-recognize-it.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/mm-pgtable-define-pte_index-so-th…
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/mm-pgtable-define-pte_index-so-th…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Mike Rapoport <rppt(a)linux.ibm.com>
Subject: mm/pgtable: define pte_index so that preprocessor could recognize it
Since commit 974b9b2c68f3 ("mm: consolidate pte_index() and pte_offset_*()
definitions") pte_index is a static inline and there is no define for it
that can be recognized by the preprocessor. As a result,
vm_insert_pages() uses slower loop over vm_insert_page() instead of
insert_pages() that amortizes the cost of spinlock operations when
inserting multiple pages.
Link: https://lkml.kernel.org/r/20220111145457.20748-1-rppt@kernel.org
Fixes: 974b9b2c68f3 ("mm: consolidate pte_index() and pte_offset_*() definitions")
Signed-off-by: Mike Rapoport <rppt(a)linux.ibm.com>
Reported-by: Christian Dietrich <stettberger(a)dokucode.de>
Reviewed-by: Khalid Aziz <khalid.aziz(a)oracle.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/pgtable.h | 1 +
1 file changed, 1 insertion(+)
--- a/include/linux/pgtable.h~mm-pgtable-define-pte_index-so-that-preprocessor-could-recognize-it
+++ a/include/linux/pgtable.h
@@ -62,6 +62,7 @@ static inline unsigned long pte_index(un
{
return (address >> PAGE_SHIFT) & (PTRS_PER_PTE - 1);
}
+#define pte_index pte_index
#ifndef pmd_index
static inline unsigned long pmd_index(unsigned long address)
_
Patches currently in -mm which might be from rppt(a)linux.ibm.com are
mm-pgtable-define-pte_index-so-that-preprocessor-could-recognize-it.patch
The patch titled
Subject: coredump: also dump first pages of non-executable ELF libraries
has been added to the -mm tree. Its filename is
coredump-also-dump-first-pages-of-non-executable-elf-libraries.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/coredump-also-dump-first-pages-of…
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/coredump-also-dump-first-pages-of…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Jann Horn <jannh(a)google.com>
Subject: coredump: also dump first pages of non-executable ELF libraries
When I rewrote the VMA dumping logic for coredumps, I changed it to
recognize ELF library mappings based on the file being executable instead
of the mapping having an ELF header. But turns out, distros ship many ELF
libraries as non-executable, so the heuristic goes wrong...
Restore the old behavior where FILTER(ELF_HEADERS) dumps the first page of
any offset-0 readable mapping that starts with the ELF magic.
This fix is technically layer-breaking a bit, because it checks for
something ELF-specific in fs/coredump.c; but since we probably want to
share this between standard ELF and FDPIC ELF anyway, I guess it's fine?
And this also keeps the change small for backporting.
Link: https://lkml.kernel.org/r/20220126025739.2014888-1-jannh@google.com
Fixes: 429a22e776a2 ("coredump: rework elf/elf_fdpic vma_dump_size() into c=
ommon helper")
Signed-off-by: Jann Horn <jannh(a)google.com>
Reported-by: Bill Messmer <wmessmer(a)microsoft.com>
Cc: "Eric W . Biederman" <ebiederm(a)xmission.com>
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: Randy Dunlap <rdunlap(a)infradead.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/coredump.c | 39 ++++++++++++++++++++++++++++++++++-----
1 file changed, 34 insertions(+), 5 deletions(-)
--- a/fs/coredump.c~coredump-also-dump-first-pages-of-non-executable-elf-libraries
+++ a/fs/coredump.c
@@ -42,6 +42,7 @@
#include <linux/path.h>
#include <linux/timekeeping.h>
#include <linux/sysctl.h>
+#include <linux/elf.h>
#include <linux/uaccess.h>
#include <asm/mmu_context.h>
@@ -980,6 +981,8 @@ static bool always_dump_vma(struct vm_ar
return false;
}
+#define DUMP_SIZE_MAYBE_ELFHDR_PLACEHOLDER 1
+
/*
* Decide how much of @vma's contents should be included in a core dump.
*/
@@ -1039,9 +1042,20 @@ static unsigned long vma_dump_size(struc
* dump the first page to aid in determining what was mapped here.
*/
if (FILTER(ELF_HEADERS) &&
- vma->vm_pgoff == 0 && (vma->vm_flags & VM_READ) &&
- (READ_ONCE(file_inode(vma->vm_file)->i_mode) & 0111) != 0)
- return PAGE_SIZE;
+ vma->vm_pgoff == 0 && (vma->vm_flags & VM_READ)) {
+ if ((READ_ONCE(file_inode(vma->vm_file)->i_mode) & 0111) != 0)
+ return PAGE_SIZE;
+
+ /*
+ * ELF libraries aren't always executable.
+ * We'll want to check whether the mapping starts with the ELF
+ * magic, but not now - we're holding the mmap lock,
+ * so copy_from_user() doesn't work here.
+ * Use a placeholder instead, and fix it up later in
+ * dump_vma_snapshot().
+ */
+ return DUMP_SIZE_MAYBE_ELFHDR_PLACEHOLDER;
+ }
#undef FILTER
@@ -1116,8 +1130,6 @@ int dump_vma_snapshot(struct coredump_pa
m->end = vma->vm_end;
m->flags = vma->vm_flags;
m->dump_size = vma_dump_size(vma, cprm->mm_flags);
-
- vma_data_size += m->dump_size;
}
mmap_write_unlock(mm);
@@ -1127,6 +1139,23 @@ int dump_vma_snapshot(struct coredump_pa
return -EFAULT;
}
+ for (i = 0; i < *vma_count; i++) {
+ struct core_vma_metadata *m = (*vma_meta) + i;
+
+ if (m->dump_size == DUMP_SIZE_MAYBE_ELFHDR_PLACEHOLDER) {
+ char elfmag[SELFMAG];
+
+ if (copy_from_user(elfmag, (void __user *)m->start, SELFMAG) ||
+ memcmp(elfmag, ELFMAG, SELFMAG) != 0) {
+ m->dump_size = 0;
+ } else {
+ m->dump_size = PAGE_SIZE;
+ }
+ }
+
+ vma_data_size += m->dump_size;
+ }
+
*vma_data_size_ptr = vma_data_size;
return 0;
}
_
Patches currently in -mm which might be from jannh(a)google.com are
coredump-also-dump-first-pages-of-non-executable-elf-libraries.patch
The patch titled
Subject: mm/debug_vm_pgtable: remove pte entry from the page table
has been added to the -mm tree. Its filename is
mm-debug_vm_pgtable-remove-pte-entry-from-the-page-table.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/mm-debug_vm_pgtable-remove-pte-en…
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/mm-debug_vm_pgtable-remove-pte-en…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Pasha Tatashin <pasha.tatashin(a)soleen.com>
Subject: mm/debug_vm_pgtable: remove pte entry from the page table
Patch series "page table check fixes and cleanups", v4.
Two fixes:
mm/debug_vm_pgtable: remove pte entry from the page table
- remove a pte entry from the page table at the end of
debug_vm_pgtable pte test
mm/khugepaged: unify collapse pmd clear, flush and free
mm/page_table_check: check entries at pmd levels
- check pmd level in page_table_check for PTE regular entries
prior to freeing.
repro.c: https://gist.github.com/soleen/fdcd501d5df103976245fe84e9535087
config: https://gist.github.com/soleen/8a56f923c2fea9ce9c75b4e2517d4162
qemu_script: https://gist.github.com/soleen/f4be4795826b7ab1a51ae659582e179c
base image:
https://storage.googleapis.com/syzkaller/wheezy.imghttps://storage.googleapis.com/syzkaller/wheezy.img.key
Small cleanup:
mm/page_table_check: use unsigned long for page counters and cleanup
This patch (of 4):
The pte entry that is used in pte_advanced_tests() is never removed from
the page table at the end of the test.
The issue is detected by page_table_check, to repro compile kernel with
the following configs:
CONFIG_DEBUG_VM_PGTABLE=y
CONFIG_PAGE_TABLE_CHECK=y
CONFIG_PAGE_TABLE_CHECK_ENFORCED=y
During the boot the following BUG is printed:
[ 2.262821] debug_vm_pgtable: [debug_vm_pgtable ]: Validating
architecture page table helpers
[ 2.276826] ------------[ cut here ]------------
[ 2.280426] kernel BUG at mm/page_table_check.c:162!
[ 2.284118] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[ 2.287787] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.16.0-11413-g2c271fe77d52 #3
[ 2.293226] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org
04/01/2014
...
The entry should be properly removed from the page table before the page
is released to the free list.
Link: https://lkml.kernel.org/r/20220126183637.1840960-2-pasha.tatashin@soleen.com
Fixes: a5c3b9ffb0f4 ("mm/debug_vm_pgtable: add tests validating advanced arch page table helpers")
Signed-off-by: Pasha Tatashin <pasha.tatashin(a)soleen.com>
Reviewed-by: Zi Yan <ziy(a)nvidia.com>
Tested-by: Zi Yan <ziy(a)nvidia.com>
Acked-by: David Rientjes <rientjes(a)google.com>
Cc: Paul Turner <pjt(a)google.com>
Cc: Wei Xu <weixugc(a)google.com>
Cc: Greg Thelen <gthelen(a)google.com>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: Will Deacon <will(a)kernel.org>
Cc: Mike Rapoport <rppt(a)kernel.org>
Cc: Dave Hansen <dave.hansen(a)linux.intel.com>
Cc: H. Peter Anvin <hpa(a)zytor.com>
Cc: Aneesh Kumar K.V <aneesh.kumar(a)linux.ibm.com>
Cc: Jiri Slaby <jirislaby(a)kernel.org>
Cc: Muchun Song <songmuchun(a)bytedance.com>
Cc: Hugh Dickins <hughd(a)google.com>
Cc: Anshuman Khandual <anshuman.khandual(a)arm.com>
Cc: <stable(a)vger.kernel.org> [5.9+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/debug_vm_pgtable.c | 2 ++
1 file changed, 2 insertions(+)
--- a/mm/debug_vm_pgtable.c~mm-debug_vm_pgtable-remove-pte-entry-from-the-page-table
+++ a/mm/debug_vm_pgtable.c
@@ -171,6 +171,8 @@ static void __init pte_advanced_tests(st
ptep_test_and_clear_young(args->vma, args->vaddr, args->ptep);
pte = ptep_get(args->ptep);
WARN_ON(pte_young(pte));
+
+ ptep_get_and_clear_full(args->mm, args->vaddr, args->ptep, 1);
}
static void __init pte_savedwrite_tests(struct pgtable_debug_args *args)
_
Patches currently in -mm which might be from pasha.tatashin(a)soleen.com are
mm-debug_vm_pgtable-remove-pte-entry-from-the-page-table.patch
mm-page_table_check-use-unsigned-long-for-page-counters-and-cleanup.patch
mm-khugepaged-unify-collapse-pmd-clear-flush-and-free.patch
mm-page_table_check-check-entries-at-pmd-levels.patch
The patch titled
Subject: fs/exec: require argv[0] presence in do_execveat_common()
has been added to the -mm tree. Its filename is
fs-exec-require-argv-presence-in-do_execveat_common.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/fs-exec-require-argv-presence-in-…
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/fs-exec-require-argv-presence-in-…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Ariadne Conill <ariadne(a)dereferenced.org>
Subject: fs/exec: require argv[0] presence in do_execveat_common()
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[0]:
The argument arg0 should point to a filename string that is
associated with the process being started by one of the exec
functions.
To ensure that execve(2) with argc < 1 is not a useful tool for shellcode
to use, we can validate this in do_execveat_common() and fail for this
scenario, effectively blocking successful exploitation of CVE-2021-4034
and similar bugs which depend on execve(2) working with argc < 1.
We use -EINVAL for this case, mirroring recent changes to FreeBSD and
OpenBSD. -EINVAL is also used by QNX for this, while Solaris uses
-EFAULT.
In earlier versions of the patch, it was proposed that we create a fake
argv for applications to use when argc < 1, but it was concluded that it
would be better to just fail the execve(2) in these cases, as launching a
process with an empty or NULL argv[0] was likely to just cause more
problems.
Interestingly, Michael Kerrisk opened an issue about this in 2008[1], but
there was no consensus to support fixing this issue then. Hopefully now
that CVE-2021-4034 shows practical exploitative use[2] of this bug in a
shellcode, we can reconsider.
This issue is being tracked in the KSPP issue tracker[3].
There are a few[4][5] minor edge cases (primarily in test suites) that are
caught by this, but we plan to work with the projects to fix those edge
cases.
[0]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=8408
[2]: https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt
[3]: https://github.com/KSPP/linux/issues/176
[4]: https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+…
[5]: https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%…
Link: https://lkml.kernel.org/r/20220127000724.15106-1-ariadne@dereferenced.org
Signed-off-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: Kees Cook <keescook(a)chromium.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
fs/exec.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/fs/exec.c~fs-exec-require-argv-presence-in-do_execveat_common
+++ a/fs/exec.c
@@ -1897,6 +1897,10 @@ static int do_execveat_common(int fd, st
}
retval = count(argv, MAX_ARG_STRINGS);
+ if (retval == 0) {
+ pr_warn_once("Attempted to run process '%s' with NULL argv\n", bprm->filename);
+ retval = -EINVAL;
+ }
if (retval < 0)
goto out_free;
bprm->argc = retval;
_
Patches currently in -mm which might be from ariadne(a)dereferenced.org are
fs-exec-require-argv-presence-in-do_execveat_common.patch