Commit 591a22c14d3f ("proc: Track /proc/$pid/attr/ opener mm_struct") we
started using __mem_open() to track the mm_struct at open-time, so that
we could then check it for writes.
But that also ended up making the permission checks at open time much
stricter - and not just for writes, but for reads too. And that in turn
caused a regression for at least Fedora 29, where NIC interfaces fail to
start when using NetworkManager.
Since only the write side wanted the mm_struct test, ignore any failures
by __mem_open() at open time, leaving reads unaffected. The write()
time verification of the mm_struct pointer will then catch the failure
case because a NULL pointer will not match a valid 'current->mm'.
James Wang has reproduced it stably on the latest 4.19 LTS.
After some debugging, we finally proved that it's due to ftrace
buffer out-of-bound access using a debug tool as follows:
[ 86.775200] BUG: Out-of-bounds write at addr 0xffff88aefe8b7000
[ 86.780806] no_context+0xdf/0x3c0
[ 86.784327] __do_page_fault+0x252/0x470
[ 86.788367] do_page_fault+0x32/0x140
[ 86.792145] page_fault+0x1e/0x30
[ 86.795576] strncpy_from_unsafe+0x66/0xb0
[ 86.799789] fetch_memory_string+0x25/0x40
[ 86.804002] fetch_deref_string+0x51/0x60
[ 86.808134] kprobe_trace_func+0x32d/0x3a0
[ 86.812347] kprobe_dispatcher+0x45/0x50
[ 86.816385] kprobe_ftrace_handler+0x90/0xf0
[ 86.820779] ftrace_ops_assist_func+0xa1/0x140
[ 86.825340] 0xffffffffc00750bf
[ 86.828603] do_sys_open+0x5/0x1f0
[ 86.832124] do_syscall_64+0x5b/0x1b0
[ 86.835900] entry_SYSCALL_64_after_hwframe+0x44/0xa9
commit b220c049d519 ("tracing: Check length before giving out
the filter buffer") adds length check to protect trace data
overflow introduced in 0fc1b09ff1ff, seems that this fix can't prevent
overflow entirely, the length check should also take the sizeof
entry->array[0] into account, since this array[0] is filled the
length of trace data and occupy addtional space and risk overflow.
Link: https://<email address hidden>
Cc: <email address hidden>
Cc: Ingo Molnar <email address hidden>
Cc: Xunlei Pang <email address hidden>
Cc: Greg Kroah-Hartman <email address hidden>
Fixes: b220c049d519 ("tracing: Check length before giving out the filter buffer")
Reviewed-by: Xunlei Pang <email address hidden>
Reviewed-by: yinbinbin <email address hidden>
Reviewed-by: Wetp Zhang <email address hidden>
Tested-by: James Wang <email address hidden>
Signed-off-by: Liangyan <email address hidden>
Signed-off-by: Steven Rostedt (VMware) <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
It was reported that a bug on arm64 caused a bad ip address to be used for
updating into a nop in ftrace_init(), but the error path (rightfully)
returned -EINVAL and not -EFAULT, as the bug caused more than one error to
occur. But because -EINVAL was returned, the ftrace_bug() tried to report
what was at the location of the ip address, and read it directly. This
caused the machine to panic, as the ip was not pointing to a valid memory
address.
Instead, read the ip address with copy_from_kernel_nofault() to safely
access the memory, and if it faults, report that the address faulted,
otherwise report what was in that location.
get_device(shost->shost_gendev.parent) is called after host state has
switched to SHOST_RUNNING. scsi_host_dev_release() shouldn't release the
parent device if host state is still SHOST_CREATED.
Link: https://<email address hidden>
Cc: Bart Van Assche <email address hidden>
Cc: John Garry <email address hidden>
Cc: Hannes Reinecke <email address hidden>
Tested-by: John Garry <email address hidden>
Reviewed-by: John Garry <email address hidden>
Signed-off-by: Ming Lei <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
scsi_host_dev_release() only frees dev_name when host state is
SHOST_CREATED. After host state has changed to SHOST_RUNNING,
scsi_host_dev_release() no longer cleans up.
Fix this by doing a put_device(&shost->shost_dev) in the failure path when
host state is SHOST_RUNNING. Move get_device(&shost->shost_gendev) before
device_add(&shost->shost_dev) so that scsi_host_cls_release() can do a put
on this reference.
Link: https://<email address hidden>
Cc: Bart Van Assche <email address hidden>
Cc: Hannes Reinecke <email address hidden>
Reported-by: John Garry <email address hidden>
Tested-by: John Garry <email address hidden>
Reviewed-by: John Garry <email address hidden>
Reviewed-by: Hannes Reinecke <email address hidden>
Signed-off-by: Ming Lei <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
After device is initialized via device_initialize(), or its name is set via
dev_set_name(), the device has to be freed via put_device(). Otherwise
device name will be leaked because it is allocated dynamically in
dev_set_name().
Fix the leak by replacing kfree() with put_device(). Since
scsi_host_dev_release() properly handles IDA and kthread removal, remove
special-casing these from the error handling as well.
Link: https://<email address hidden>
Cc: Bart Van Assche <email address hidden>
Cc: John Garry <email address hidden>
Cc: Hannes Reinecke <email address hidden>
Tested-by: John Garry <email address hidden>
Reviewed-by: Bart Van Assche <email address hidden>
Reviewed-by: John Garry <email address hidden>
Reviewed-by: Hannes Reinecke <email address hidden>
Signed-off-by: Ming Lei <email address hidden>
Signed-off-by: Martin K. Petersen <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Currently if __nfs4_proc_set_acl fails with NFS4ERR_BADOWNER it
re-enables the idmapper by clearing NFS_CAP_UIDGID_NOMAP before
retrying again. The NFS_CAP_UIDGID_NOMAP remains cleared even if
the retry fails. This causes problem for subsequent setattr
requests for v4 server that does not have idmapping configured.
This patch modifies nfs4_proc_set_acl to detect NFS4ERR_BADOWNER
and NFS4ERR_BADNAME and skips the retry, since the kernel isn't
involved in encoding the ACEs, and return -EINVAL.
KASAN reports a use-after-free when attempting to mount two different
exports through two different NICs that belong to the same server.
Olga was able to hit this with kernels starting somewhere between 5.7
and 5.10, but I traced the patch that introduced the clear_bit() call to
4.13. So something must have changed in the refcounting of the clp
pointer to make this call to nfs_put_client() the very last one.
