To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for powerpc.
__LITTLE_ENDIAN__ is used here instead of CONFIG_CPU_LITTLE_ENDIAN
to keep it consistent with asm/syscall.h.
Signed-off-by: YiFei Zhu <yifeifz2@illinois.edu>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/0b64925362671cdaa26d01bfe50b3ba5e164adfd.1605101222.git.yifeifz2@illinois.edu
(cherry picked from commit e7bcb4622ddf4473da6c03fa8423919a568c57dc)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: I917b30a0c8cc6697513cc7f12bc84691e3166745
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for parisc.
Signed-off-by: YiFei Zhu <yifeifz2@illinois.edu>
Acked-by: Helge Deller <deller@gmx.de>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/9bb86c546eda753adf5270425e7353202dbce87c.1605101222.git.yifeifz2@illinois.edu
(cherry picked from commit 6aa7923c8737d1f8fd2a06154155d68dec646464)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: I48ef86a4127b9cc87dff5235ded3733c098db7e1
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for csky.
Signed-off-by: YiFei Zhu <yifeifz2@illinois.edu>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/f9219026d4803b22f3e57e3768b4e42e004ef236.1605101222.git.yifeifz2@illinois.edu
(cherry picked from commit 6e9ae6f98809e0d123ff4d769ba2e6f652119138)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: I1fea89150f06be98ea4ee4357ad441e60aa6589f
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for arm.
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 424c9102fa7b2a5c15afe47fd14278c849f4eefb)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Change-Id: I90eaafdc43f618ce7dcf76e1cbb8ae1ff542ead9
Bug: 176068146
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for arm64.
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit ffde703470b03b1000017ed35c4f90a90caa22cf)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Change-Id: Ib21059de0928a61bd76202a67732432e88c5a5f0
Bug: 176068146
As seccomp_benchmark tries to calibrate how many samples will take more
than 5 seconds to execute, it may end up picking up a number of samples
that take 10 (but up to 12) seconds. As the calibration will take double
that time, it takes around 20 seconds. Then, it executes the whole thing
again, and then once more, with some added overhead. So, the thing might
take more than 40 seconds, which is too close to the 45s timeout.
That is very dependent on the system where it's executed, so may not be
observed always, but it has been observed on x86 VMs. Using a 90s timeout
seems safe enough.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Link: https://lore.kernel.org/r/20200601123202.1183526-1-cascardo@canonical.com
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit bc32c9c86581abf7baacf71342df3b0affe367db)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: I52379d62bddc9163c6cbbb934483ceabb10cc909
The seccomp benchmark calibration loop did not need to take so long.
Instead, use a simple 1 second timeout and multiply up to target. It
does not need to be accurate.
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 81a0c8bc82be7c15dbf3e54832334552e6b76e2b)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: I5583b28bb635c01413548dbe05b2bed8d50def00
It's useful to see how much (at a minimum) each filter adds to the
syscall overhead. Add additional calculations.
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit d3a37ea9f6e548388b83fe895c7a037bc2ec3f7f)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: Ibc36b007b580cc129b2880b12b151a659590abb9
Provide seccomp internals with the details to calculate which syscall
table the running kernel is expecting to deal with. This allows for
efficient architecture pinning and paves the way for constant-action
bitmaps.
Co-developed-by: YiFei Zhu <yifeifz2@illinois.edu>
Signed-off-by: YiFei Zhu <yifeifz2@illinois.edu>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/da58c3733d95c4f2115dd94225dfbe2573ba4d87.1602431034.git.yifeifz2@illinois.edu
(cherry picked from commit 25db91209a910a0ccf8b093743088d0f4bf5659f)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Change-Id: I48a434063e401b27834e4ba37b88a852da51300b
Bug: 176068146
SECCOMP_CACHE will only operate on syscalls that do not access
any syscall arguments or instruction pointer. To facilitate
this we need a static analyser to know whether a filter will
return allow regardless of syscall arguments for a given
architecture number / syscall number pair. This is implemented
here with a pseudo-emulator, and stored in a per-filter bitmap.
In order to build this bitmap at filter attach time, each filter is
emulated for every syscall (under each possible architecture), and
checked for any accesses of struct seccomp_data that are not the "arch"
nor "nr" (syscall) members. If only "arch" and "nr" are examined, and
the program returns allow, then we can be sure that the filter must
return allow independent from syscall arguments.
Nearly all seccomp filters are built from these cBPF instructions:
BPF_LD | BPF_W | BPF_ABS
BPF_JMP | BPF_JEQ | BPF_K
BPF_JMP | BPF_JGE | BPF_K
BPF_JMP | BPF_JGT | BPF_K
BPF_JMP | BPF_JSET | BPF_K
BPF_JMP | BPF_JA
BPF_RET | BPF_K
BPF_ALU | BPF_AND | BPF_K
Each of these instructions are emulated. Any weirdness or loading
from a syscall argument will cause the emulator to bail.
The emulation is also halted if it reaches a return. In that case,
if it returns an SECCOMP_RET_ALLOW, the syscall is marked as good.
Emulator structure and comments are from Kees [1] and Jann [2].
Emulation is done at attach time. If a filter depends on more
filters, and if the dependee does not guarantee to allow the
syscall, then we skip the emulation of this syscall.
[1] https://lore.kernel.org/lkml/20200923232923.3142503-5-keescook@chromium.org/
[2] https://lore.kernel.org/lkml/CAG48ez1p=dR_2ikKq=xVxkoGg0fYpTBpkhJSv1w-6BG=76PAvw@mail.gmail.com/
Suggested-by: Jann Horn <jannh@google.com>
Signed-off-by: YiFei Zhu <yifeifz2@illinois.edu>
Reviewed-by: Jann Horn <jannh@google.com>
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/71c7be2db5ee08905f41c3be5c1ad6e2601ce88f.1602431034.git.yifeifz2@illinois.edu
(cherry picked from commit 8e01b51a31a1e08e2c3e8fcc0ef6790441be2f61)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Change-Id: I5047f7f0d6502e5de6c047743f1053fda3025a6e
Bug: 176068146
The overhead of running Seccomp filters has been part of some past
discussions [1][2][3]. Oftentimes, the filters have a large number
of instructions that check syscall numbers one by one and jump based
on that. Some users chain BPF filters which further enlarge the
overhead. A recent work [6] comprehensively measures the Seccomp
overhead and shows that the overhead is non-negligible and has a
non-trivial impact on application performance.
We observed some common filters, such as docker's [4] or
systemd's [5], will make most decisions based only on the syscall
numbers, and as past discussions considered, a bitmap where each bit
represents a syscall makes most sense for these filters.
The fast (common) path for seccomp should be that the filter permits
the syscall to pass through, and failing seccomp is expected to be
an exceptional case; it is not expected for userspace to call a
denylisted syscall over and over.
When it can be concluded that an allow must occur for the given
architecture and syscall pair (this determination is introduced in
the next commit), seccomp will immediately allow the syscall,
bypassing further BPF execution.
Each architecture number has its own bitmap. The architecture
number in seccomp_data is checked against the defined architecture
number constant before proceeding to test the bit against the
bitmap with the syscall number as the index of the bit in the
bitmap, and if the bit is set, seccomp returns allow. The bitmaps
are all clear in this patch and will be initialized in the next
commit.
When only one architecture exists, the check against architecture
number is skipped, suggested by Kees Cook [7].
[1] https://lore.kernel.org/linux-security-module/c22a6c3cefc2412cad00ae14c1371711@huawei.com/T/
[2] https://lore.kernel.org/lkml/202005181120.971232B7B@keescook/T/
[3] https://github.com/seccomp/libseccomp/issues/116
[4] ae0ef82b90/profiles/seccomp/default.json
[5] 6743a1caf4/src/shared/seccomp-util.c (L270)
[6] Draco: Architectural and Operating System Support for System Call Security
https://tianyin.github.io/pub/draco.pdf, MICRO-53, Oct. 2020
[7] https://lore.kernel.org/bpf/202010091614.8BB0EB64@keescook/
Co-developed-by: Dimitrios Skarlatos <dskarlat@cs.cmu.edu>
Signed-off-by: Dimitrios Skarlatos <dskarlat@cs.cmu.edu>
Signed-off-by: YiFei Zhu <yifeifz2@illinois.edu>
Reviewed-by: Jann Horn <jannh@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/10f91a367ec4fcdea7fc3f086de3f5f13a4a7436.1602431034.git.yifeifz2@illinois.edu
(cherry picked from commit f9d480b6ffbeb336bf7f6ce44825c00f61b3abae)A
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Change-Id: I50b6682e17dc6e91b5e92017361200d722282825
Bug: 176068146
As described in commit a3460a5974 ("new helper: current_pt_regs()"):
- arch versions are "optimized versions".
- some architectures have task_pt_regs() working only for traced tasks
blocked on signal delivery. current_pt_regs() needs to work for *all*
processes.
In preparation for adding a coccinelle rule for using current_*(), instead
of raw accesses to current members, modify seccomp_do_user_notification(),
__seccomp_filter(), __secure_computing() to use current_pt_regs().
Signed-off-by: Denis Efremov <efremov@linux.com>
Link: https://lore.kernel.org/r/20200824125921.488311-1-efremov@linux.com
[kees: Reworded commit log, add comment to populate_seccomp_data()]
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 2d9ca267a944c2b6ed5b4d750b1cf0407b6262b4)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: Ib66bcc8cfa077c7a493fb9d14501279f32f48550
Asynchronous termination of a thread outside of the userspace thread
library's knowledge is an unsafe operation that leaves the process in
an inconsistent, corrupt, and possibly unrecoverable state. In order
to make new actions that may be added in the future safe on kernels
not aware of them, change the default action from
SECCOMP_RET_KILL_THREAD to SECCOMP_RET_KILL_PROCESS.
Signed-off-by: Rich Felker <dalias@libc.org>
Link: https://lore.kernel.org/r/20200829015609.GA32566@brightrain.aerifal.cx
[kees: Fixed up coredump selection logic to match]
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 4d671d922d51907bc41f1f7f2dc737c928ae78fd)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: I23140e1efbb4346de8566421c35d2810de26b209
Christian and Kees both pointed out that this is a bit sloppy to open-code
both places, and Christian points out that we leave a dangling pointer to
->notif if file allocation fails. Since we check ->notif for null in order
to determine if it's ok to install a filter, this means people won't be
able to install a filter if the file allocation fails for some reason, even
if they subsequently should be able to.
To fix this, let's hoist this free+null into its own little helper and use
it.
Reported-by: Kees Cook <keescook@chromium.org>
Reported-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Tycho Andersen <tycho@tycho.pizza>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Link: https://lore.kernel.org/r/20200902140953.1201956-1-tycho@tycho.pizza
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit e839317900e9f13c83d8711d684de88c625b307a)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: Ie20e79fa15b6891895b7ada1f6ef7d08fdf81e01
In seccomp_set_mode_filter() with TSYNC | NEW_LISTENER, we first initialize
the listener fd, then check to see if we can actually use it later in
seccomp_may_assign_mode(), which can fail if anyone else in our thread
group has installed a filter and caused some divergence. If we can't, we
partially clean up the newly allocated file: we put the fd, put the file,
but don't actually clean up the *memory* that was allocated at
filter->notif. Let's clean that up too.
To accomplish this, let's hoist the actual "detach a notifier from a
filter" code to its own helper out of seccomp_notify_release(), so that in
case anyone adds stuff to init_listener(), they only have to add the
cleanup code in one spot. This does a bit of extra locking and such on the
failure path when the filter is not attached, but it's a slow failure path
anyway.
Fixes: 51891498f2da ("seccomp: allow TSYNC and USER_NOTIF together")
Reported-by: syzbot+3ad9614a12f80994c32e@syzkaller.appspotmail.com
Signed-off-by: Tycho Andersen <tycho@tycho.pizza>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Link: https://lore.kernel.org/r/20200902014017.934315-1-tycho@tycho.pizza
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit a566a9012acd7c9a4be7e30dc7acb7a811ec2260)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: I8e6ce0f1646ff997623458f25b733ba79c0a47a2
This allows the seccomp notifier to continue a syscall. A positive
discussion about this feature was triggered by a post to the
ksummit-discuss mailing list (cf. [3]) and took place during KSummit
(cf. [1]) and again at the containers/checkpoint-restore
micro-conference at Linux Plumbers.
Recently we landed seccomp support for SECCOMP_RET_USER_NOTIF (cf. [4])
which enables a process (watchee) to retrieve an fd for its seccomp
filter. This fd can then be handed to another (usually more privileged)
process (watcher). The watcher will then be able to receive seccomp
messages about the syscalls having been performed by the watchee.
This feature is heavily used in some userspace workloads. For example,
it is currently used to intercept mknod() syscalls in user namespaces
aka in containers.
The mknod() syscall can be easily filtered based on dev_t. This allows
us to only intercept a very specific subset of mknod() syscalls.
Furthermore, mknod() is not possible in user namespaces toto coelo and
so intercepting and denying syscalls that are not in the whitelist on
accident is not a big deal. The watchee won't notice a difference.
In contrast to mknod(), a lot of other syscall we intercept (e.g.
setxattr()) cannot be easily filtered like mknod() because they have
pointer arguments. Additionally, some of them might actually succeed in
user namespaces (e.g. setxattr() for all "user.*" xattrs). Since we
currently cannot tell seccomp to continue from a user notifier we are
stuck with performing all of the syscalls in lieu of the container. This
is a huge security liability since it is extremely difficult to
correctly assume all of the necessary privileges of the calling task
such that the syscall can be successfully emulated without escaping
other additional security restrictions (think missing CAP_MKNOD for
mknod(), or MS_NODEV on a filesystem etc.). This can be solved by
telling seccomp to resume the syscall.
One thing that came up in the discussion was the problem that another
thread could change the memory after userspace has decided to let the
syscall continue which is a well known TOCTOU with seccomp which is
present in other ways already.
The discussion showed that this feature is already very useful for any
syscall without pointer arguments. For any accidentally intercepted
non-pointer syscall it is safe to continue.
For syscalls with pointer arguments there is a race but for any cautious
userspace and the main usec cases the race doesn't matter. The notifier
is intended to be used in a scenario where a more privileged watcher
supervises the syscalls of lesser privileged watchee to allow it to get
around kernel-enforced limitations by performing the syscall for it
whenever deemed save by the watcher. Hence, if a user tricks the watcher
into allowing a syscall they will either get a deny based on
kernel-enforced restrictions later or they will have changed the
arguments in such a way that they manage to perform a syscall with
arguments that they would've been allowed to do anyway.
In general, it is good to point out again, that the notifier fd was not
intended to allow userspace to implement a security policy but rather to
work around kernel security mechanisms in cases where the watcher knows
that a given action is safe to perform.
/* References */
[1]: https://linuxplumbersconf.org/event/4/contributions/560
[2]: https://linuxplumbersconf.org/event/4/contributions/477
[3]: https://lore.kernel.org/r/20190719093538.dhyopljyr5ns33qx@brauner.io
[4]: commit 6a21cc50f0 ("seccomp: add a return code to trap to userspace")
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Reviewed-by: Tycho Andersen <tycho@tycho.ws>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Will Drewry <wad@chromium.org>
CC: Tyler Hicks <tyhicks@canonical.com>
Link: https://lore.kernel.org/r/20190920083007.11475-2-christian.brauner@ubuntu.com
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit fb3c5386b382d4097476ce9647260fc89b34afdb)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: Ifd5de971a0da6a507cb8ca1178381ca715693e07
The terminator for the mode 1 syscalls list was a 0, but that could be
a valid syscall number (e.g. x86_64 __NR_read). By luck, __NR_read was
listed first and the loop construct would not test it, so there was no
bug. However, this is fragile. Replace the terminator with -1 instead,
and make the variable name for mode 1 syscall lists more descriptive.
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Will Drewry <wad@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit fe4bfff86ec54773df3db79e8112e3b0f820c799)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: I3d91bf57236f2c20d71f22fa9c0ef7b0b8869bcf
We've been making heavy use of the seccomp notifier to intercept and
handle certain syscalls for containers. This patch allows a syscall
supervisor listening on a given notifier to be notified when a seccomp
filter has become unused.
A container is often managed by a singleton supervisor process the
so-called "monitor". This monitor process has an event loop which has
various event handlers registered. If the user specified a seccomp
profile that included a notifier for various syscalls then we also
register a seccomp notify even handler. For any container using a
separate pid namespace the lifecycle of the seccomp notifier is bound to
the init process of the pid namespace, i.e. when the init process exits
the filter must be unused.
If a new process attaches to a container we force it to assume a seccomp
profile. This can either be the same seccomp profile as the container
was started with or a modified one. If the attaching process makes use
of the seccomp notifier we will register a new seccomp notifier handler
in the monitor's event loop. However, when the attaching process exits
we can't simply delete the handler since other child processes could've
been created (daemons spawned etc.) that have inherited the seccomp
filter and so we need to keep the seccomp notifier fd alive in the event
loop. But this is problematic since we don't get a notification when the
seccomp filter has become unused and so we currently never remove the
seccomp notifier fd from the event loop and just keep accumulating fds
in the event loop. We've had this issue for a while but it has recently
become more pressing as more and larger users make use of this.
To fix this, we introduce a new "users" reference counter that tracks any
tasks and dependent filters making use of a filter. When a notifier is
registered waiting tasks will be notified that the filter is now empty
by receiving a (E)POLLHUP event.
The concept in this patch introduces is the same as for signal_struct,
i.e. reference counting for life-cycle management is decoupled from
reference counting taks using the object. There's probably some trickery
possible but the second counter is just the correct way of doing this
IMHO and has precedence.
Cc: Tycho Andersen <tycho@tycho.ws>
Cc: Kees Cook <keescook@chromium.org>
Cc: Matt Denton <mpdenton@google.com>
Cc: Sargun Dhillon <sargun@sargun.me>
Cc: Jann Horn <jannh@google.com>
Cc: Chris Palmer <palmer@google.com>
Cc: Aleksa Sarai <cyphar@cyphar.com>
Cc: Robert Sesek <rsesek@google.com>
Cc: Jeffrey Vander Stoep <jeffv@google.com>
Cc: Linux Containers <containers@lists.linux-foundation.org>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Link: https://lore.kernel.org/r/20200531115031.391515-3-christian.brauner@ubuntu.com
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 99cdb8b9a57393b5978e7a6310a2cba511dd179b)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: I1501f5134bf738fa641c8b35ed65a4bed01e6fef
Lift the wait_queue from struct notification into struct seccomp_filter.
This is cleaner overall and lets us avoid having to take the notifier
mutex in the future for EPOLLHUP notifications since we need to neither
read nor modify the notifier specific aspects of the seccomp filter. In
the exit path I'd very much like to avoid having to take the notifier mutex
for each filter in the task's filter hierarchy.
Cc: Tycho Andersen <tycho@tycho.ws>
Cc: Kees Cook <keescook@chromium.org>
Cc: Matt Denton <mpdenton@google.com>
Cc: Sargun Dhillon <sargun@sargun.me>
Cc: Jann Horn <jannh@google.com>
Cc: Chris Palmer <palmer@google.com>
Cc: Aleksa Sarai <cyphar@cyphar.com>
Cc: Robert Sesek <rsesek@google.com>
Cc: Jeffrey Vander Stoep <jeffv@google.com>
Cc: Linux Containers <containers@lists.linux-foundation.org>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 76194c4e830d570d9e369d637bb907591d2b3111)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: Id87b359f1155d26068cd62d5295dc39849d46495
The seccomp filter used to be released in free_task() which is called
asynchronously via call_rcu() and assorted mechanisms. Since we need
to inform tasks waiting on the seccomp notifier when a filter goes empty
we will notify them as soon as a task has been marked fully dead in
release_task(). To not split seccomp cleanup into two parts, move
filter release out of free_task() and into release_task() after we've
unhashed struct task from struct pid, exited signals, and unlinked it
from the threadgroups' thread list. We'll put the empty filter
notification infrastructure into it in a follow up patch.
This also renames put_seccomp_filter() to seccomp_filter_release() which
is a more descriptive name of what we're doing here especially once
we've added the empty filter notification mechanism in there.
We're also NULL-ing the task's filter tree entrypoint which seems
cleaner than leaving a dangling pointer in there. Note that this shouldn't
need any memory barriers since we're calling this when the task is in
release_task() which means it's EXIT_DEAD. So it can't modify its seccomp
filters anymore. You can also see this from the point where we're calling
seccomp_filter_release(). It's after __exit_signal() and at this point,
tsk->sighand will already have been NULLed which is required for
thread-sync and filter installation alike.
Cc: Tycho Andersen <tycho@tycho.ws>
Cc: Kees Cook <keescook@chromium.org>
Cc: Matt Denton <mpdenton@google.com>
Cc: Sargun Dhillon <sargun@sargun.me>
Cc: Jann Horn <jannh@google.com>
Cc: Chris Palmer <palmer@google.com>
Cc: Aleksa Sarai <cyphar@cyphar.com>
Cc: Robert Sesek <rsesek@google.com>
Cc: Jeffrey Vander Stoep <jeffv@google.com>
Cc: Linux Containers <containers@lists.linux-foundation.org>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Link: https://lore.kernel.org/r/20200531115031.391515-2-christian.brauner@ubuntu.com
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 3a15fb6ed92cb32b0a83f406aa4a96f28c9adbc3)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Resolved minor merge conflict in kernel/exit.c where 5.4 does not have
commits 7bc3e6e55acf0 and 6ade99ec6175a.
Change-Id: I4a0113f3f64a86937ba5c9ac6e2537926e2827be
Naming the lifetime counter of a seccomp filter "usage" suggests a
little too strongly that its about tasks that are using this filter
while it also tracks other references such as the user notifier or
ptrace. This also updates the documentation to note this fact.
We'll be introducing an actual usage counter in a follow-up patch.
Cc: Tycho Andersen <tycho@tycho.ws>
Cc: Kees Cook <keescook@chromium.org>
Cc: Matt Denton <mpdenton@google.com>
Cc: Sargun Dhillon <sargun@sargun.me>
Cc: Jann Horn <jannh@google.com>
Cc: Chris Palmer <palmer@google.com>
Cc: Aleksa Sarai <cyphar@cyphar.com>
Cc: Robert Sesek <rsesek@google.com>
Cc: Jeffrey Vander Stoep <jeffv@google.com>
Cc: Linux Containers <containers@lists.linux-foundation.org>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Link: https://lore.kernel.org/r/20200531115031.391515-1-christian.brauner@ubuntu.com
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit b707ddee11d1dc4518ab7f1aa5e7af9ceaa23317)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: If4c78f85b9873aea2dffa1c8afb250f534d0fedc
This adds a helper which can iterate through a seccomp_filter to
find a notification matching an ID. It removes several replicated
chunks of code.
Signed-off-by: Sargun Dhillon <sargun@sargun.me>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Reviewed-by: Tycho Andersen <tycho@tycho.ws>
Cc: Matt Denton <mpdenton@google.com>
Cc: Kees Cook <keescook@google.com>,
Cc: Jann Horn <jannh@google.com>,
Cc: Robert Sesek <rsesek@google.com>,
Cc: Chris Palmer <palmer@google.com>
Cc: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Tycho Andersen <tycho@tycho.ws>
Link: https://lore.kernel.org/r/20200601112532.150158-1-sargun@sargun.me
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 9f87dcf14b82b05ff0e26970439b372ae135de0c)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: I328edd8717fc06a415f7d4cf4fe561d86b2d4682
A common question asked when debugging seccomp filters is "how many
filters are attached to your process?" Provide a way to easily answer
this question through /proc/$pid/status with a "Seccomp_filters" line.
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit c818c03b661cd769e035e41673d5543ba2ebda64)
Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
Bug: 176068146
Change-Id: Ib189ea77511a6088d5d328706c77c88709d8d63e
commit 5cb249686e67dbef3ffe53887fa725eefc5a7144 upstream.
addrconf_prefix_rcv returned early without releasing the inet6_dev
pointer when the PIO lifetime is less than accept_ra_min_lft.
Change-Id: Ic633a1ea28c96f712dce8875f24227ce02ab86b0
Fixes: 5027d54a9c30 ("net: change accept_ra_min_rtr_lft to affect all RA lifetimes")
Cc: Maciej Żenczykowski <maze@google.com>
Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: David Ahern <dsahern@kernel.org>
Cc: Simon Horman <horms@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: Patrick Rohr <prohr@google.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5027d54a9c30bc7ec808360378e2b4753f053f25 upstream.
accept_ra_min_rtr_lft only considered the lifetime of the default route
and discarded entire RAs accordingly.
This change renames accept_ra_min_rtr_lft to accept_ra_min_lft, and
applies the value to individual RA sections; in particular, router
lifetime, PIO preferred lifetime, and RIO lifetime. If any of those
lifetimes are lower than the configured value, the specific RA section
is ignored.
In order for the sysctl to be useful to Android, it should really apply
to all lifetimes in the RA, since that is what determines the minimum
frequency at which RAs must be processed by the kernel. Android uses
hardware offloads to drop RAs for a fraction of the minimum of all
lifetimes present in the RA (some networks have very frequent RAs (5s)
with high lifetimes (2h)). Despite this, we have encountered networks
that set the router lifetime to 30s which results in very frequent CPU
wakeups. Instead of disabling IPv6 (and dropping IPv6 ethertype in the
WiFi firmware) entirely on such networks, it seems better to ignore the
misconfigured routers while still processing RAs from other IPv6 routers
on the same network (i.e. to support IoT applications).
The previous implementation dropped the entire RA based on router
lifetime. This turned out to be hard to expand to the other lifetimes
present in the RA in a consistent manner; dropping the entire RA based
on RIO/PIO lifetimes would essentially require parsing the whole thing
twice.
Change-Id: I2168608875629ae07bbd30a02a061284110693e7
Fixes: 1671bcfd76fd ("net: add sysctl accept_ra_min_rtr_lft")
Cc: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Patrick Rohr <prohr@google.com>
Reviewed-by: Maciej Żenczykowski <maze@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20230726230701.919212-1-prohr@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1671bcfd76fdc0b9e65153cf759153083755fe4c upstream.
This change adds a new sysctl accept_ra_min_rtr_lft to specify the
minimum acceptable router lifetime in an RA. If the received RA router
lifetime is less than the configured value (and not 0), the RA is
ignored.
This is useful for mobile devices, whose battery life can be impacted
by networks that configure RAs with a short lifetime. On such networks,
the device should never gain IPv6 provisioning and should attempt to
drop RAs via hardware offload, if available.
Change-Id: I5e575f2e2d303c6736fc5e983b65003c7e7a075a
Signed-off-by: Patrick Rohr <prohr@google.com>
Cc: Maciej Żenczykowski <maze@google.com>
Cc: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 52cc02b910284d6bddba46cce402044ab775f314 upstream.
LLVM_IAS is the user interface to set the -(no-)integrated-as flag,
and it should be used only for that purpose.
LLVM_IAS is checked in some places to determine the assembler type,
but it is not precise.
For example,
$ make CC=gcc LLVM_IAS=1
... will use the GNU assembler (i.e. binutils) since LLVM_IAS=1 is
effective only when $(CC) is clang.
Of course, 'CC=gcc LLVM_IAS=1' is an odd combination, but the build
system can be more robust against such insane input.
Commit ba64beb17493a ("kbuild: check the minimum assembler version in
Kconfig") introduced CONFIG_AS_IS_GNU/LLVM, which is more precise
because Kconfig checks the version string from the assembler in use.
Change-Id: I190f91350cdb4305a01cabc80d952b0541aef521
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
[nathan: Backport to 5.10]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2185a7e4b0ade86c2c57fc63d4a7535c40254bd0 upstream.
It has been brought up a few times in various code reviews that clang
3.5 introduced -f{,no-}integrated-as as the preferred way to enable and
disable the integrated assembler, mentioning that -{no-,}integrated-as
are now considered legacy flags.
Switch the kernel over to using those variants in case there is ever a
time where clang decides to remove the non-'f' variants of the flag.
Also, fix a typo in a comment ("intergrated" -> "integrated").
Link: https://releases.llvm.org/3.5.0/tools/clang/docs/ReleaseNotes.html#new-compiler-flags
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Change-Id: Id848bd57d5e27afb85cf51c26d9312751168407e
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
[nathan: Backport to 5.10]
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Documentation/process/changes.rst defines the minimum assembler version
(binutils version), but we have never checked it in the build time.
Kbuild never invokes 'as' directly because all assembly files in the
kernel tree are *.S, hence must be preprocessed. I do not expect
raw assembly source files (*.s) would be added to the kernel tree.
Therefore, we always use $(CC) as the assembler driver, and commit
aa824e0c962b ("kbuild: remove AS variable") removed 'AS'. However,
we are still interested in the version of the assembler acting behind.
As usual, the --version option prints the version string.
$ as --version | head -n 1
GNU assembler (GNU Binutils for Ubuntu) 2.35.1
But, we do not have $(AS). So, we can add the -Wa prefix so that
$(CC) passes --version down to the backing assembler.
$ gcc -Wa,--version | head -n 1
gcc: fatal error: no input files
compilation terminated.
OK, we need to input something to satisfy gcc.
$ gcc -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
GNU assembler (GNU Binutils for Ubuntu) 2.35.1
The combination of Clang and GNU assembler works in the same way:
$ clang -no-integrated-as -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
GNU assembler (GNU Binutils for Ubuntu) 2.35.1
Clang with the integrated assembler fails like this:
$ clang -integrated-as -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
clang: error: unsupported argument '--version' to option 'Wa,'
For the last case, checking the error message is fragile. If the
proposal for -Wa,--version support [1] is accepted, this may not be
even an error in the future.
One easy way is to check if -integrated-as is present in the passed
arguments. We did not pass -integrated-as to CLANG_FLAGS before, but
we can make it explicit.
Nathan pointed out -integrated-as is the default for all of the
architectures/targets that the kernel cares about, but it goes
along with "explicit is better than implicit" policy. [2]
With all this in my mind, I implemented scripts/as-version.sh to
check the assembler version in Kconfig time.
$ scripts/as-version.sh gcc
GNU 23501
$ scripts/as-version.sh clang -no-integrated-as
GNU 23501
$ scripts/as-version.sh clang -integrated-as
LLVM 0
[1]: https://github.com/ClangBuiltLinux/linux/issues/1320
[2]: https://lore.kernel.org/linux-kbuild/20210307044253.v3h47ucq6ng25iay@archlinux-ax161/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
[nd: conflict in arch/Kconfig due to missing dc5723b02e523 ("kbuild: add
support for Clang LTO") which landed in v5.12-rc1]
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
(cherry picked from commit ba64beb17493a4bfec563100c86a462a15926f24)
Bug: 210043760
Change-Id: I9bcc528adbb86fa902123611ce979af0dd455ad5
commit f4c3b83b75b91c5059726cb91e3165cc01764ce7 upstream.
With commit 1e860048c53e ("gcc-plugins: simplify GCC plugin-dev
capability test") applied, this hunk can be way simplified because
now scripts/gcc-plugins/Kconfig only checks plugin-version.h
Change-Id: Ic718951bcba65cdfe92ac2b8b6857ad96424408c
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit b3d9fc1436808a4ef9927e558b3415e728e710c5 ]
There is a test in Kconfig which takes inverted value of a compiler
check:
* config CC_HAS_INT128
def_bool !$(cc-option,$(m64-flag) -D__SIZEOF_INT128__=0)
This results in CC_HAS_INT128 not being in super-config generated by
dummy-tools. So take this into account in the gcc script.
Change-Id: Iaf7eb5d969bd92617c622a164bf7a2db58675932
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Staring v4.18, Kconfig evaluates compiler capabilities, and hides CONFIG
options your compiler does not support. This works well if you configure
and build the kernel on the same host machine.
It is inconvenient if you prepare the .config that is carried to a
different build environment (typically this happens when you package
the kernel for distros) because using a different compiler potentially
produces different CONFIG options than the real build environment.
So, you probably want to make as many options visible as possible.
In other words, you need to create a super-set of CONFIG options that
cover any build environment. If some of the CONFIG options turned out
to be unsupported on the build machine, they are automatically disabled
by the nature of Kconfig.
However, it is not feasible to get a full-featured compiler for every
arch.
This issue was discussed here:
https://lkml.org/lkml/2019/12/9/620
Other than distros, savedefconfig is also a problem. Some arch sub-systems
periodically resync defconfig files. If you use a less-capable compiler
for savedefconfig, options that do not meet 'depends on $(cc-option,...)'
will be forcibly disabled. So, 'make defconfig && make savedefconfig'
may silently change the behavior.
This commit adds a set of dummy toolchains that pretend to support any
feature.
Most of compiler features are tested by cc-option, which simply checks
the exit code of $(CC). The dummy tools are shell scripts that always
exit with 0. So, $(cc-option, ...) is evaluated as 'y'.
There are more complicated checks such as:
scripts/gcc-x86_{32,64}-has-stack-protector.sh
scripts/gcc-plugin.sh
scripts/tools-support-relr.sh
scripts/dummy-tools/gcc passes all checks.
From the top directory of the source tree, you can do:
$ make CROSS_COMPILE=scripts/dummy-tools/ oldconfig
Change-Id: Ic0ed9f3c73888a14c38c5ce546bc171b479c35ed
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Tested-by: Jeremy Cline <jcline@redhat.com>
Change reason:to support the background speed limit function, we need to enable the configs as follow:
CONFIG_NET_SCH_PRIO=y [*]
CONFIG_NET_SCH_MULTIQ=y [*]
CONFIG_NET_SCH_TBF=y
CONFIG_NET_SCH_NETEM=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_FLOW=y
CONFIG_NET_EMATCH_CMP=y
CONFIG_NET_EMATCH_NBYTE=y
CONFIG_NET_EMATCH_META=y
CONFIG_NET_EMATCH_TEXT=y
CONFIG_NET_ACT_POLICE=y [*]
CONFIG_NET_ACT_GACT=y [*]
CONFIG_NET_ACT_MIRRED=y [*]
CONFIG_NET_ACT_SKBEDIT=y
[*] additionally enabled during backport to android11-5.4 to match 5.10+
Bug: 189705988
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: liuwei.a <liuwei.a@oppo.com>
Change-Id: I6f9a627bc2a2197b0da8a371ccd2a762b3147fc1
(cherry picked from commit da4b3a9637de63da6259e43bd4c0ead9504a8e40)
Currently, overlap calculation did not distinguish between ION and
non-ION buffers. This could result in incorrect offsets when an ION
buffer overlapped with a non-ION buffer, leading to out-of-bounds
writes and potential security issues. Calculate overlap ranges
separately for ION and non-ION buffers.
Change-Id: If5eb57d447b68d58d8821ecfbf2d9375b2cd1f8e
Signed-off-by: Ramesh Nallagopu <quic_rnallago@quicinc.com>
In case of unaligned start address and NOVA flag set, range validation
is by-passed. The page size calculated using unaligned address passed by
user is aligned to nearest boundary internally which returns page size
4KB more. In order to avoid out of bounds issue, check page range is within
map range.
Change-Id: Ie2de944206eee0730c8ba081f05b7d7cccc72276
Signed-off-by: Om Deore <quic_odeore@quicinc.com>
When deallocating dma-buf metadata in kgsl_destroy_ion, the priv_data
pointer in the associated kgsl_mem_entry structure is not reset after
kfree(). To avoid use after free, set entry->priv_data to NULL
immediately after freeing metadata.
Change-Id: Ia222d3a88666b7ee406f1508eb37a4eef766c83e
Signed-off-by: Shiv Kumar <shikum@qti.qualcomm.com>
Signed-off-by: Pankaj Gupta <gpankaj@qti.qualcomm.com>
This reverts commit 525fb1b48f.
Reason for revert: Breaks WiFi, likely needs additional changes to be
backported for it to work properly.
Change-Id: Ifc537c0dc80d759a9ab12671c7ff053ad6c31759
LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0
* tag 'LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0' of https://git.codelinaro.org/clo/la/platform/vendor/opensource/video-driver:
msm: vidc: Fix use after free in driver
msm: vidc: Enable hybrid mode only for HFR usecase
Change-Id: Ic2a5c64a04bcd2bed2c853f541255b7563d9b65c
LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0
* tag 'LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0' of https://git.codelinaro.org/clo/la/platform/vendor/opensource/dataipa:
ipa: Added changes to move the hdr entry to free list
msm: ipa: Avoid use-after-free scenario
Change-Id: I53d9b6e5cd83948d5a7cd67b8b7ffa58af13efef
LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0
* tag 'LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0' of https://git.codelinaro.org/clo/la/platform/vendor/opensource/audio-kernel:
asoc: lsm: thread safety issue in hw params management
asoc: lsm: Race condition protection in confidence levels handling
asoc: lsm: thread safety issue while accessing substream data
asoc: compress: race condition handling in stream cmd put function
asoc: handle heap overflow in effect driver
asoc: Update dai link for ACM8625S AMP.
asoc: Modification for 8ch capture
audio-kernel: Fix wcd938x DMIC unable to record
audio-kernel: Enable hdmi in audio function for AIO bar
dsp: q6adm: Checking array sizeof channel_type
asoc: codec: avoid out of bound write to map array
dsp: q6lsm: Check size of payload before access
Change-Id: I9eebb44e5b838891dc094853e28535930dee6b83
LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0
* tag 'LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0' of https://git.codelinaro.org/clo/la/platform/vendor/qcom-opensource/wlan/qcacld-3.0:
qcacld-3.0: Populate MBSSID cap in Ext CAP IE
Release 2.0.8.35G
qcacld-3.0: Fix underflow issue of beacon length
Release 2.0.8.35F
qcacld-3.0: don't overwrite psd_power flag if psd_set is true
qcacld-3.0: Add TPE IE EIRP power support for 6 GHz band
Release 2.0.8.35E
qcacld-3.0: Validate bw in lim calculate tpc
qcacld-3.0: Add Validation for WMA Handle and PSOC in Wake Event
Release 2.0.8.35D
qcacld-3.0: Add ini to apply RSSI delta for 6 GHz roam
Release 2.0.8.35C
qcacld-3.0: Update PMK from firmware for FT-SAE AKM also
Release 2.0.8.35B
qcacld-3.0: Rename variables name chan to chan_freq of wlan_hdd_mgmt_tx
qcacld-3.0: Fix mgmt tx from supplicant failed on 6 GHz chan
Release 2.0.8.35A
qcacld-3.0: Fix potential OOB memory access
Release 2.0.8.35
qcacld-3.0: Recalculate TX power post CSA
qcacld-3.0: Correcting the TSInfo structure size according to the Spec
qcacld-3.0: Fix the possible OOB write in country IE unpack
qcacld-3.0: Enhance the RSNXE inter-op logic
qcacld-3.0: Fix the AKM precedence order for RSN IE
qcacld-3.0: Update connect request crypto parameters
qcacld-3.0: Enable CFG80211_MULTI_AKM_CONNECT_SUPPORT from kernelv6.0
qcacld-3.0: Update wiphy max_num_akms_connect variable
Change-Id: I87412b74b79c527b7c867dd61b062ad38da8aab3
LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0
* tag 'LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0' of https://git.codelinaro.org/clo/la/platform/vendor/qcom-opensource/wlan/qca-wifi-host-cmn:
qcacmn: Validate vdev count before pdev CSA switch count update
qcacmn: Fix out of bounds read in extract_roam_scan_ap_stats_tlv
qcacmn: Update is_psd_power logic in reg get client pwr API
qcacmn: Keep counter atomicity while logging
qcacmn: Avoid OOB read in reg fill master channel API
qcacmn: Add macro to determine WPA3 AKM
qcacmn: Correct RSNXE capability indexes
Change-Id: I99ee7720aa22bc6dcfe52505d883498d767c7f09
Revert "reverting all USB patches"
This reverts commit 365834436c.
Conflicts:
drivers/usb/core/quirks.c
drivers/usb/dwc3/dwc3-qcom.c
drivers/usb/host/xhci-plat.c
drivers/usb/serial/option.c
Partially revert "reverting enum-conversion, Handle CPU state and all USB patches"
This partially reverts commit 2c3bda25f8.
Conflicts:
drivers/usb/core/quirks.c
drivers/usb/dwc3/gadget.c
drivers/usb/gadget/function/f_fs.c
drivers/usb/serial/option.c
Change-Id: I89f5ca04b3306fddb8b9ebd5382ec495ff9e1030
LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0
* tag 'LA.UM.9.14.1.r1-21100-QCM6490.QISI15.0' of https://git.codelinaro.org/clo/la/kernel/msm-5.4:
msm:kgsl: Prevent sign extension on alignments
reverting all USB patches
msm: eva: OOB write issue in fence processing
kgsl: gmu: Use num_vma for safe GMU VMAs array access
net: Add netdevice notification for bridge activity
bridge: port structure members from 5.4 kernel
net: bridge: Fix for co-located mode
UPSTREAM: usb: gadget: configfs: Add frame-based frame format support
kgsl: Add buffer overflow check for perfcounter dynamic list
usb: gadget: uvc: Add grey and I420 YUV UVC format support
mtd: msm_qpic_nand: Use flash device ECC capability for erase page
mtd: msm_qpic_nand: check for page_erased bit along with op_err
UPSTREAM: usb: dwc3: Wait for EndXfer command completion
netfilter: fix NATTYPE refresh timeout issue
usb: gadget: uvc: Modify UVC_NUM_REQUESTS
reverting enum-conversion, Handle CPU state and all USB patches
msm: cvp: Fix for kernel address exposure vulnerability to user
cnss: Init reserved memory device
cnss: Dump stack by stack_trace_print
cnss: Add support for building CNSS as a loadable module
FROMLIST: media: venus: Add a check for packet size
Add configures to enable CNSS platform driver
FROMLIST: media: venus: Fix OOB read due to missing payload bound check
dma-mapping-fast: Fix PMD offset calculation for non-2M aligned start aperture
crypto: qcedev - fix UAF in crypto-qti driver
msm: adsprpc: Prevent refcount increment for duplicate dmahandles
dmaengine: msm_gpi: fix to avoid null pointer access
mdm: ipa3: support IPoGRE new IOCTL and proc params
msm: mhi_dev: Workqueue to handle host wakeup in M3+D0
iommu: Fix invalid access in av8l_fast_unmap_public
msm: mhi_dev: Handle host wakeup in M3/D0
msm: ep_pcie: Wake host in D3cold handling if wake is pending
FROMGIT: media: venus: hfi: add a check to handle OOB in sfr region
FROMGIT: media: venus: hfi: add check to handle incorrect queue size
FROMGIT: media: venus: hfi_parser: add check to avoid out of bound access
Revert "msm_ipa: Install exception rule for PPPoE-MPLS"
firmware: qcom_scm: do not clear dump mode from shutdown
msm: adsprpc: Avoid taking reference for group_info
adsprpc: Handle UAF scenario in put_args
msm: eva: Adding kref count for cvp_get_inst_from_id
wifi: cfg80211: Increase akm_suites array size in cfg80211_crypto_settings
thermal: qcom: Add support to update tsens trip based on nvmem data
Conflicts:
Makefile
arch/arm64/include/asm/cputype.h
drivers/char/adsprpc.c
drivers/hid/hid-ids.h
drivers/net/usb/rtl8150.c
drivers/platform/Kconfig
drivers/platform/Makefile
drivers/soc/qcom/mdt_loader.c
drivers/soc/qcom/rpmh-rsc.c
drivers/usb/core/quirks.c
drivers/usb/dwc3/dwc3-qcom.c
drivers/usb/dwc3/gadget.c
drivers/usb/gadget/function/f_fs.c
drivers/usb/gadget/function/f_ncm.c
mm/slub.c
mm/zsmalloc.c
net/ipv4/tcp_output.c
scripts/Makefile.extrawarn
Change-Id: Ia4f3356ed4a105a2f3b0feda3e78725a01a970b2
