While working on commit b5372fe5 ("exec: load_script: Do not exec
truncated interpreter path"), I wrote a series of test scripts to verify
corner cases. However, soon after, commit 6eb3c3d0 ("exec: increase
BINPRM_BUF_SIZE to 256") landed, resulting in the tests needing to be
refactored for the larger BINPRM_BUF_SIZE, which got lost on my TODO
list. During the recent exec refactoring work[1], the need for these tests
resurfaced, so I've finished them up for addition to the kernel selftests.

[1] https://lore.kernel.org/lkml/202005191144.E3112135@keescook/

Link: https://lkml.kernel.org/r/202005200204.D07DF079@keescookSigned-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>

It is hard to follow the control flow in exec.c as the code has evolved over
time and something that used to work one way now works another.  This set of
changes attempts to address the worst of that, to remove unnecessary work
and to make the code a little easier to follow.

The churn is a bit higher than the last version of this patchset, with
renaming and cleaning up of comments.  I have split security_bprm_set_creds
into security_bprm_creds_for_exec and security_bprm_repopulate_creds.  My
goal was to make it clear that one hook completes its work while the other
recaculates it's work each time a new interpreter is selected.

I have added a new change at the beginning to make it clear that neither
security_bprm_creds_for_exec nor security_bprm_repopulate_creds needs to be
implemented as prepare_exec_creds properly does the work of setting up
credentials unless something special is going on.

I have made the execfd support generic and moved out of binfmt_misc so that
I can remove the recursion.

I have moved reassigning bprm->file into the loop that replaces the
recursion.  In doing so I discovered that binfmt_misc was naughty and
was returning -ENOEXEC in such a way that the search_binary_handler loop
could not continue.  So I added a change to remove that naughtiness.

Eric W. Biederman (8):
      exec: Teach prepare_exec_creds how exec treats uids & gids
      exec: Factor security_bprm_creds_for_exec out of security_bprm_set_creds
      exec: Convert security_bprm_set_creds into security_bprm_repopulate_creds
      exec: Allow load_misc_binary to call prepare_binfmt unconditionally
      exec: Move the call of prepare_binprm into search_binary_handler
      exec/binfmt_script: Don't modify bprm->buf and then return -ENOEXEC
      exec: Generic execfd support
      exec: Remove recursion from search_binary_handler

 arch/alpha/kernel/binfmt_loader.c  | 11 +----
 fs/binfmt_elf.c                    |  4 +-
 fs/binfmt_elf_fdpic.c              |  4 +-
 fs/binfmt_em86.c                   | 13 +----
 fs/binfmt_misc.c                   | 69 ++++-----------------------
 fs/binfmt_script.c                 | 82 ++++++++++++++------------------
 fs/exec.c                          | 97 ++++++++++++++++++++++++++------------
 include/linux/binfmts.h            | 36 ++++++--------
 include/linux/lsm_hook_defs.h      |  3 +-
 include/linux/lsm_hooks.h          | 52 +++++++++++---------
 include/linux/security.h           | 14 ++++--
 kernel/cred.c                      |  3 ++
 security/apparmor/domain.c         |  7 +--
 security/apparmor/include/domain.h |  2 +-
 security/apparmor/lsm.c            |  2 +-
 security/commoncap.c               |  9 ++--
 security/security.c                |  9 +++-
 security/selinux/hooks.c           |  8 ++--
 security/smack/smack_lsm.c         |  9 ++--
 security/tomoyo/tomoyo.c           | 12 ++---
 20 files changed, 202 insertions(+), 244 deletions(-)

Link: https://lkml.kernel.org/r/877dx822er.fsf_-_@x220.int.ebiederm.orgAcked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

Recursion in kernel code is generally a bad idea as it can overflow
the kernel stack.  Recursion in exec also hides that the code is
looping and that the loop changes bprm->file.

Instead of recursing in search_binary_handler have the methods that
would recurse set bprm->interpreter and return 0.  Modify exec_binprm
to loop when bprm->interpreter is set.  Consolidate all of the
reassignments of bprm->file in that loop to make it clear what is
going on.

The structure of the new loop in exec_binprm is that all errors return
immediately, while successful completion (ret == 0 &&
!bprm->interpreter) just breaks out of the loop and runs what
exec_bprm has always run upon successful completion.

Fail if the an interpreter is being call after execfd has been set.
The code has never properly handled an interpreter being called with
execfd being set and with reassignments of bprm->file and the
assignment of bprm->executable in generic code it has finally become
possible to test and fail when if this problematic condition happens.

With the reassignments of bprm->file and the assignment of
bprm->executable moved into the generic code add a test to see if
bprm->executable is being reassigned.

In search_binary_handler remove the test for !bprm->file.  With all
reassignments of bprm->file moved to exec_binprm bprm->file can never
be NULL in search_binary_handler.

Link: https://lkml.kernel.org/r/87sgfwyd84.fsf_-_@x220.int.ebiederm.orgAcked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

Most of the support for passing the file descriptor of an executable
to an interpreter already lives in the generic code and in binfmt_elf.
Rework the fields in binfmt_elf that deal with executable file
descriptor passing to make executable file descriptor passing a first
class concept.

Move the fd_install from binfmt_misc into begin_new_exec after the new
creds have been installed.  This means that accessing the file through
/proc/<pid>/fd/N is able to see the creds for the new executable
before allowing access to the new executables files.

Performing the install of the executables file descriptor after
the point of no return also means that nothing special needs to
be done on error.  The exiting of the process will close all
of it's open files.

Move the would_dump from binfmt_misc into begin_new_exec right
after would_dump is called on the bprm->file.  This makes it
obvious this case exists and that no nesting of bprm->file is
currently supported.

In binfmt_misc the movement of fd_install into generic code means
that it's special error exit path is no longer needed.

Link: https://lkml.kernel.org/r/87y2poyd91.fsf_-_@x220.int.ebiederm.orgAcked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

The return code -ENOEXEC serves to tell search_binary_handler that it
should continue searching for the binfmt to handle a given file.  This
makes return -ENOEXEC with a bprm->buf that is needed to continue the
search problematic.

The current binfmt_script manages to escape problems as it closes and
clears bprm->file before return -ENOEXEC with bprm->buf modified.
This prevents search_binary_handler from looping as it explicitly
handles a NULL bprm->file.

I plan on moving all of the bprm->file managment into fs/exec.c and out
of the binary handlers so this will become a problem.

Move closing bprm->file and the test for BINPRM_PATH_INACCESSIBLE
down below the last return of -ENOEXEC.

Introduce i_sep and i_end to track the end of the first argument and
the end of the parameters respectively.  Using those, constification
of all char * pointers, and the helpers next_terminator and
next_non_spacetab guarantee the parameter parsing will not modify
bprm->buf.

Only modify bprm->buf to terminate the strings i_arg and i_name with
'\0' for passing to copy_strings_kernel.

When replacing loops with next_non_spacetab and next_terminator care
has been take that the logic of the parsing code (short of replacing
characters by '\0') remains the same.

Link: https://lkml.kernel.org/r/874ksczru6.fsf_-_@x220.int.ebiederm.orgAcked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

The code in prepare_binary_handler needs to be run every time
search_binary_handler is called so move the call into search_binary_handler
itself to make the code simpler and easier to understand.

Link: https://lkml.kernel.org/r/87d070zrvx.fsf_-_@x220.int.ebiederm.orgAcked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NJames Morris <jamorris@linux.microsoft.com>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

Add a flag preserve_creds that binfmt_misc can set to prevent
credentials from being updated.  This allows binfmt_misc to always
call prepare_binprm.  Allowing the credential computation logic to be
consolidated.

Not replacing the credentials with the interpreters credentials is
safe because because an open file descriptor to the executable is
passed to the interpreter.   As the interpreter does not need to
reopen the executable it is guaranteed to see the same file that
exec sees.

Ref: c407c033de84 ("[PATCH] binfmt_misc: improve calculation of interpreter's credentials")
Link: https://lkml.kernel.org/r/87imgszrwo.fsf_-_@x220.int.ebiederm.orgAcked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

Rename bprm->cap_elevated to bprm->active_secureexec and initialize it
in prepare_binprm instead of in cap_bprm_set_creds.  Initializing
bprm->active_secureexec in prepare_binprm allows multiple
implementations of security_bprm_repopulate_creds to play nicely with
each other.

Rename security_bprm_set_creds to security_bprm_reopulate_creds to
emphasize that this path recomputes part of bprm->cred.  This
recomputation avoids the time of check vs time of use problems that
are inherent in unix #! interpreters.

In short two renames and a move in the location of initializing
bprm->active_secureexec.

Link: https://lkml.kernel.org/r/87o8qkzrxp.fsf_-_@x220.int.ebiederm.orgAcked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

Today security_bprm_set_creds has several implementations:
apparmor_bprm_set_creds, cap_bprm_set_creds, selinux_bprm_set_creds,
smack_bprm_set_creds, and tomoyo_bprm_set_creds.

Except for cap_bprm_set_creds they all test bprm->called_set_creds and
return immediately if it is true.  The function cap_bprm_set_creds
ignores bprm->calld_sed_creds entirely.

Create a new LSM hook security_bprm_creds_for_exec that is called just
before prepare_binprm in __do_execve_file, resulting in a LSM hook
that is called exactly once for the entire of exec.  Modify the bits
of security_bprm_set_creds that only want to be called once per exec
into security_bprm_creds_for_exec, leaving only cap_bprm_set_creds
behind.

Remove bprm->called_set_creds all of it's former users have been moved
to security_bprm_creds_for_exec.

Add or upate comments a appropriate to bring them up to date and
to reflect this change.

Link: https://lkml.kernel.org/r/87v9kszrzh.fsf_-_@x220.int.ebiederm.orgAcked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Acked-by: Casey Schaufler <casey@schaufler-ca.com> # For the LSM and Smack bits
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

It is almost possible to use the result of prepare_exec_creds with no
modifications during exec.  Update prepare_exec_creds to initialize
the suid and the fsuid to the euid, and the sgid and the fsgid to the
egid.  This is all that is needed to handle the common case of exec
when nothing special like a setuid exec is happening.

That this preserves the existing behavior of exec can be verified
by examing bprm_fill_uid and cap_bprm_set_creds.

This change makes it clear that the later parts of exec that
update bprm->cred are just need to handle special cases such
as setuid exec and change of domains.

Link: https://lkml.kernel.org/r/871rng22dm.fsf_-_@x220.int.ebiederm.orgAcked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

The change to exec is relevant to the cleanup work I have been doing.

Merge it here so that I can build on top of it, and so hopefully
that other merge logic can pick up on this and see how to deal
with the conflict between that change and my exec cleanup work.
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

I goofed when I added mm->user_ns support to would_dump.  I missed the
fact that in the case of binfmt_loader, binfmt_em86, binfmt_misc, and
binfmt_script bprm->file is reassigned.  Which made the move of
would_dump from setup_new_exec to __do_execve_file before exec_binprm
incorrect as it can result in would_dump running on the script instead
of the interpreter of the script.

The net result is that the code stopped making unreadable interpreters
undumpable.  Which allows them to be ptraced and written to disk
without special permissions.  Oops.

The move was necessary because the call in set_new_exec was after
bprm->mm was no longer valid.

To correct this mistake move the misplaced would_dump from
__do_execve_file into flos_old_exec, before exec_mmap is called.

I tested and confirmed that without this fix I can attach with gdb to
a script with an unreadable interpreter, and with this fix I can not.

Cc: stable@vger.kernel.org
Fixes: f84df2a6 ("exec: Ensure mm->user_ns contains the execed files")
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

This is a continuation of my work to clean up exec so it's more
difficult problems are approachable.

The changes correct some comments, and moves the point_of_no_return
variable up to when the point_of_no_return actually occurs.

Eric W. Biederman (5):
      exec: Move the comment from above de_thread to above unshare_sighand
      exec: Fix spelling of search_binary_handler in a comment
      exec: Run sync_mm_rss before taking exec_update_mutex
      exec: Move handling of the point of no return to the top level
      exec: Set the point of no return sooner

 fs/exec.c | 46 ++++++++++++++++++++++++----------------------
 1 file changed, 24 insertions(+), 22 deletions(-)

Link: https://lkml.kernel.org/r/87sgga6ze4.fsf@x220.int.ebiederm.orgSigned-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

Make the code more robust by marking the point of no return sooner.
This ensures that future code changes don't need to worry about how
they return errors if they are past this point.

This results in no actual change in behavior as __do_execve_file does
not force SIGSEGV when there is a pending fatal signal pending past
the point of no return.  Further the only error returns from de_thread
and exec_mmap that can occur result in fatal signals being pending.
Reviewed-by: NKees Cook <keescook@chromium.org>
Link: https://lkml.kernel.org/r/87sgga5klu.fsf_-_@x220.int.ebiederm.orgSigned-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

Move the handing of the point of no return from search_binary_handler
into __do_execve_file so that it is easier to find, and to keep
things robust in the face of change.

Make it clear that an existing fatal signal will take precedence over
a forced SIGSEGV by not forcing SIGSEGV if a fatal signal is already
pending.  This does not change the behavior but it saves a reader
of the code the tedium of reading and understanding force_sig
and the signal delivery code.

Update the comment in begin_new_exec about where SIGSEGV is forced.

Keep point_of_no_return from being a mystery by documenting
what the code is doing where it forces SIGSEGV if the
code is past the point of no return.
Reviewed-by: NKees Cook <keescook@chromium.org>
Link: https://lkml.kernel.org/r/87y2q25knl.fsf_-_@x220.int.ebiederm.orgSigned-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

Like exec_mm_release sync_mm_rss is about flushing out the state of
the old_mm, which does not need to happen under exec_update_mutex.

Make this explicit by moving sync_mm_rss outside of exec_update_mutex.
Reviewed-by: NKees Cook <keescook@chromium.org>
Link: https://lkml.kernel.org/r/875zd66za3.fsf_-_@x220.int.ebiederm.orgSigned-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

Link: https://lkml.kernel.org/r/87h7wq6zc1.fsf_-_@x220.int.ebiederm.orgReviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

The comment describes work that now happens in unshare_sighand so
move the comment where it makes sense.

Link: https://lkml.kernel.org/r/87mu6i6zcs.fsf_-_@x220.int.ebiederm.orgReviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

In the patchset that introduced exec_update_mutex there were a few last
minute discoveries and fixes that left the code in a state that can
be very easily be improved.

During the merge window we discussed the first three of these patches
and I promised I would resend them.

What the first patch does is it makes the the calls in the binfmts:
	flush_old_exec();
        /* set the personality */
        setup_new_exec();
        install_exec_creds();

With no sleeps or anything in between.

At the conclusion of this set of changes the the calls in the binfmts
are:
	begin_new_exec();
        /* set the personality */
        setup_new_exec();

The intent is to make the code easier to follow and easier to change.

Eric W. Biederman (7):
      binfmt: Move install_exec_creds after setup_new_exec to match binfmt_elf
      exec: Make unlocking exec_update_mutex explict
      exec: Rename the flag called_exec_mmap point_of_no_return
      exec: Merge install_exec_creds into setup_new_exec
      exec: In setup_new_exec cache current in the local variable me
      exec: Move most of setup_new_exec into flush_old_exec
      exec: Rename flush_old_exec begin_new_exec

 Documentation/trace/ftrace.rst |   2 +-
 arch/x86/ia32/ia32_aout.c      |   4 +-
 fs/binfmt_aout.c               |   3 +-
 fs/binfmt_elf.c                |   3 +-
 fs/binfmt_elf_fdpic.c          |   3 +-
 fs/binfmt_flat.c               |   4 +-
 fs/exec.c                      | 162 ++++++++++++++++++++---------------------
 include/linux/binfmts.h        |  10 +--
 kernel/events/core.c           |   2 +-
 9 files changed, 92 insertions(+), 101 deletions(-)

Link: https://lkml.kernel.org/r/87h7wujhmz.fsf@x220.int.ebiederm.orgReviewed-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NGreg Ungerer <gerg@linux-m68k.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

There is and has been for a very long time been a lot more going on in
flush_old_exec than just flushing the old state.  After the movement
of code from setup_new_exec there is a whole lot more going on than
just flushing the old executables state.

Rename flush_old_exec to begin_new_exec to more accurately reflect
what this function does.
Reviewed-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NGreg Ungerer <gerg@linux-m68k.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

The current idiom for the callers is:

flush_old_exec(bprm);
set_personality(...);
setup_new_exec(bprm);

In 2010 Linus split flush_old_exec into flush_old_exec and
setup_new_exec.  With the intention that setup_new_exec be what is
called after the processes new personality is set.

Move the code that doesn't depend upon the personality from
setup_new_exec into flush_old_exec.  This is to facilitate future
changes by having as much code together in one function as possible.

To see why it is safe to move this code please note that effectively
this change moves the personality setting in the binfmt and the following
three lines of code after everything except unlocking the mutexes:
	arch_pick_mmap_layout
	arch_setup_new_exec
	mm->task_size = TASK_SIZE

The function arch_pick_mmap_layout at most sets:
	mm->get_unmapped_area
	mm->mmap_base
	mm->mmap_legacy_base
	mm->mmap_compat_base
	mm->mmap_compat_legacy_base
which nothing in flush_old_exec or setup_new_exec depends on.

The function arch_setup_new_exec only sets architecture specific
state and the rest of the functions only deal in state that applies
to all architectures.

The last line just sets mm->task_size and again nothing in flush_old_exec
or setup_new_exec depend on task_size.

Ref: 221af7f8 ("Split 'flush_old_exec' into two functions")
Reviewed-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NGreg Ungerer <gerg@linux-m68k.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

At least gcc 8.3 when generating code for x86_64 has a hard time
consolidating multiple calls to current aka get_current(), and winds
up unnecessarily rereading %gs:current_task several times in
setup_new_exec.

Caching the value of current in the local variable of me generates
slightly better and shorter assembly.
Reviewed-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NGreg Ungerer <gerg@linux-m68k.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

The two functions are now always called one right after the
other so merge them together to make future maintenance easier.
Reviewed-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NGreg Ungerer <gerg@linux-m68k.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

Update the comments and make the code easier to understand by
renaming this flag.
Reviewed-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NGreg Ungerer <gerg@linux-m68k.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

With install_exec_creds updated to follow immediately after
setup_new_exec, the failure of unshare_sighand is the only
code path where exec_update_mutex is held but not explicitly
unlocked.

Update that code path to explicitly unlock exec_update_mutex.

Remove the unlocking of exec_update_mutex from free_bprm.
Reviewed-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NGreg Ungerer <gerg@linux-m68k.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

In 2016 Linus moved install_exec_creds immediately after
setup_new_exec, in binfmt_elf as a cleanup and as part of closing a
potential information leak.

Perform the same cleanup for the other binary formats.

Different binary formats doing the same things the same way makes exec
easier to reason about and easier to maintain.

Greg Ungerer reports:
> I tested the the whole series on non-MMU m68k and non-MMU arm
> (exercising binfmt_flat) and it all tested out with no problems,
> so for the binfmt_flat changes:
Tested-by: NGreg Ungerer <gerg@linux-m68k.org>

Ref: 9f834ec1 ("binfmt_elf: switch to new creds when switching to new mm")
Reviewed-by: NKees Cook <keescook@chromium.org>
Reviewed-by: NGreg Ungerer <gerg@linux-m68k.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>

Pull cifs fixes from Steve French:
 "Five cifs/smb3 fixes:two for DFS reconnect failover, one lease fix for
  stable and the others to fix a missing spinlock during reconnect"

* tag '5.7-rc2-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6:
  cifs: fix uninitialised lease_key in open_shroot()
  cifs: ensure correct super block for DFS reconnect
  cifs: do not share tcons with DFS
  cifs: minor update to comments around the cifs_tcp_ses_lock mutex
  cifs: protect updating server->dstaddr with a spinlock

Pull USB fixes from Greg KH:
 "Here are a number of USB driver fixes for 5.7-rc3.

  Nothing huge, just the usual collection of:

   - xhci fixes

   - gadget driver fixes

   - syzkaller fuzzing fixes

   - new device ids and DT bindings

   - new quirks added for broken devices

  A few of the gadget driver fixes show up twice here as they were
  applied to my branch, and also by Felipe to his branch which I then
  pulled in as we got out of sync a bit.

  All of these have been in linux-next with no reported issues"

* tag 'usb-5.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (33 commits)
  USB: sisusbvga: Change port variable from signed to unsigned
  usb-storage: Add unusual_devs entry for JMicron JMS566
  USB: hub: Revert commit bd0e6c96 ("usb: hub: try old enumeration scheme first for high speed devices")
  USB: hub: Fix handling of connect changes during sleep
  usb: typec: altmode: Fix typec_altmode_get_partner sometimes returning an invalid pointer
  xhci: Don't clear hub TT buffer on ep0 protocol stall
  xhci: prevent bus suspend if a roothub port detected a over-current condition
  xhci: Fix handling halted endpoint even if endpoint ring appears empty
  usb: raw-gadget: Fix copy_to/from_user() checks
  usb: raw-gadget: fix raw_event_queue_fetch locking
  usb: gadget: udc: atmel: Fix vbus disconnect handling
  usb: dwc3: gadget: Fix request completion check
  USB: Add USB_QUIRK_DELAY_CTRL_MSG and USB_QUIRK_DELAY_INIT for Corsair K70 RGB RAPIDFIRE
  phy: tegra: Select USB_COMMON for usb_get_maximum_speed()
  usb: typec: tcpm: Ignore CC and vbus changes in PORT_RESET change
  usb: f_fs: Clear OS Extended descriptor counts to zero in ffs_data_reset()
  cdc-acm: introduce a cool down
  cdc-acm: close race betrween suspend() and acm_softint
  UAS: fix deadlock in error handling and PM flushing work
  UAS: no use logging any details in case of ENODEV
  ...

Pull tty/serial fixes from Greg KH:
 "Here are some tty and serial driver fixes for 5.7-rc3.

  The "largest" in here are a number of reverts for previous changes to
  the uartps serial driver that turned out to not be a good idea at all.

  The others are just small fixes found by people and tools. Included in
  here is a much-reported symbol export needed by previous changes that
  happened in 5.7-rc1. All of these have been in linux-next for a while
  with no reported issues"

* tag 'tty-5.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  tty: hvc: fix buffer overflow during hvc_alloc().
  tty: rocket, avoid OOB access
  tty: serial: bcm63xx: fix missing clk_put() in bcm63xx_uart
  vt: don't hardcode the mem allocation upper bound
  tty: serial: owl: add "much needed" clk_prepare_enable()
  vt: don't use kmalloc() for the unicode screen buffer
  tty/sysrq: Export sysrq_mask(), sysrq_toggle_support()
  serial: sh-sci: Make sure status register SCxSR is read in correct sequence
  serial: sunhv: Initialize lock for non-registered console
  Revert "serial: uartps: Register own uart console and driver structures"
  Revert "serial: uartps: Move Port ID to device data structure"
  Revert "serial: uartps: Change uart ID port allocation"
  Revert "serial: uartps: Do not allow use aliases >= MAX_UART_INSTANCES"
  Revert "serial: uartps: Fix error path when alloc failed"
  Revert "serial: uartps: Use the same dynamic major number for all ports"
  Revert "serial: uartps: Fix uartps_major handling"

Pull char/misc driver fixes from Greg KH:
 "Here are 4 small misc driver fixes for 5.7-rc3:

   - mei driver fix

   - interconnect driver fix

   - two fpga driver fixes

  All have been in linux-next with no reported issues"

* tag 'char-misc-5.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  interconnect: qcom: Fix uninitialized tcs_cmd::wait
  mei: me: fix irq number stored in hw struct
  fpga: dfl: pci: fix return value of cci_pci_sriov_configure
  fpga: zynq: Remove clk_get error message for probe defer

Pull staging/IIO driver fixes from Greg KH:
 "Here are some small staging and IIO driver fixes for 5.7-rc3

  Lots of tiny things for reported issues in staging and IIO drivers,
  including a counter driver fix as well (the iio drivers seem to be
  tied to those). Full details of the fixes are in the shortlog.

  All of these have been in linux-next for a while with no reported
  issues"

* tag 'staging-5.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (27 commits)
  staging: vt6656: Fix calling conditions of vnt_set_bss_mode
  staging: comedi: Fix comedi_device refcnt leak in comedi_open
  staging: vt6656: Fix pairwise key entry save.
  staging: vt6656: Fix drivers TBTT timing counter.
  staging: vt6656: Don't set RCR_MULTICAST or RCR_BROADCAST by default.
  MAINTAINERS: remove Stefan Popa's email
  iio: adc: ad7192: fix null pointer de-reference crash during probe
  iio: core: remove extra semi-colon from devm_iio_device_register() macro
  iio: adc: ti-ads8344: properly byte swap value
  iio: imu: inv_mpu6050: fix suspend/resume with runtime power
  iio: st_sensors: rely on odr mask to know if odr can be set
  iio: xilinx-xadc: Make sure not exceed maximum samplerate
  iio: xilinx-xadc: Fix sequencer configuration for aux channels in simultaneous mode
  iio: xilinx-xadc: Fix clearing interrupt when enabling trigger
  iio: xilinx-xadc: Fix ADC-B powerdown
  iio: dac: ad5770r: fix off-by-one check on maximum number of channels
  iio: imu: st_lsm6dsx: flush hw FIFO before resetting the device
  iio: core: Fix handling of 'dB'
  dt-bindings: iio: adc: stm32-adc: fix id relative path
  counter: 104-quad-8: Add lock guards - generic interface
  ...

Pull driver core fixes from Greg KH:
 "Here are some small firmware/driver core/debugfs fixes for 5.7-rc3.

  The debugfs change is now possible as now the last users of
  debugfs_create_u32() have been fixed up in the different trees that
  got merged into 5.7-rc1, and I don't want it creeping back in.

  The firmware changes did cause a regression in linux-next, so the
  final patch here reverts part of that, re-exporting the symbol to
  resolve that issue. All of these patches, with the exception of the
  final one, have been in linux-next with only that one reported issue"

* tag 'driver-core-5.7-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  firmware_loader: revert removal of the fw_fallback_config export
  debugfs: remove return value of debugfs_create_u32()
  firmware_loader: remove unused exports
  firmware: imx: fix compile-testing

Pull s390 fixes from Vasily Gorbik:

 - Add a few notrace annotations to avoid potential crashes when
   switching ftrace tracers.

 - Avoid setting affinity for floating irqs in pci code.

 - Fix build issue found by kbuild test robot.

* tag 's390-5.7-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/protvirt: fix compilation issue
  s390/pci: do not set affinity for floating irqs
  s390/ftrace: fix potential crashes when switching tracers

Pull powerpc fixes from Michael Ellerman:

 - One important fix for a bug in the way we find the cache-line size
   from the device tree, which was leading to the wrong size being
   reported to userspace on some platforms.

 - A fix for 8xx STRICT_KERNEL_RWX which was leaving TLB entries around
   leading to a window at boot when the strict mapping wasn't enforced.

 - A fix to enable our KUAP (kernel user access prevention) debugging on
   PPC32.

 - A build fix for clang in lib/mpi.

Thanks to: Chris Packham, Christophe Leroy, Nathan Chancellor, Qian Cai.

* tag 'powerpc-5.7-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  lib/mpi: Fix building for powerpc with clang
  powerpc/mm: Fix CONFIG_PPC_KUAP_DEBUG on PPC32
  powerpc/8xx: Fix STRICT_KERNEL_RWX startup test failure
  powerpc/setup_64: Set cache-line-size based on cache-block-size

Pull more Devicetree fixes from Rob Herring:
 "A couple of schema and kbuild fixes"

* tag 'devicetree-fixes-for-5.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
  dt-bindings: phy: qcom-qusb2: Fix defaults
  dt-bindings: Fix erroneous 'additionalProperties'
  dt-bindings: Fix command line length limit calling dt-mk-schema
  dt-bindings: Re-enable core schemas for dtbs_check

Christoph's patch removed two unsused exported symbols, however, one
symbol is used by the firmware_loader itself.  If CONFIG_FW_LOADER=m so
the firmware_loader is modular but CONFIG_FW_LOADER_USER_HELPER=y we fail
the build at mostpost.

ERROR: modpost: "fw_fallback_config" [drivers/base/firmware_loader/firmware_class.ko] undefined!

This happens because the variable fw_fallback_config is built into the
kernel if CONFIG_FW_LOADER_USER_HELPER=y always, so we need to grant
access to the firmware loader module by exporting it.

Revert only one hunk from his patch.

Fixes: 73960473 ("firmware_loader: remove unused exports")
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NLuis Chamberlain <mcgrof@kernel.org>
Link: https://lore.kernel.org/r/20200424184916.22843-1-mcgrof@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Pull pid leak fix from Eric Biederman:
 "Oleg noticed that put_pid(thread_pid) was not getting called when proc
  was not compiled in.

  Let's get that fixed before 5.7 is released and causes problems for
  anyone"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace:
  proc: Put thread_pid in release_task not proc_flush_pid

Pull timer fixlet from Ingo Molnar:
 "A single fix for a comment that may show up in DocBook output"

* tag 'timers-urgent-2020-04-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  vdso/datapage: Use correct clock mode name in comment

Pull scheduler fixes from Ingo Molnar:
 "Misc fixes:

   - an uclamp accounting fix

   - three frequency invariance fixes and a readability improvement"

* tag 'sched-urgent-2020-04-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/core: Fix reset-on-fork from RT with uclamp
  x86, sched: Move check for CPU type to caller function
  x86, sched: Don't enable static key when starting secondary CPUs
  x86, sched: Account for CPUs with less than 4 cores in freq. invariance
  x86, sched: Bail out of frequency invariance if base frequency is unknown