23 Aug, 2018
40 commits
-
The varable names got a mess, thus standardize them again:
id: user space id. Called semid, shmid, msgid if the type is known.
Most functions use "id" already.
idx: "index" for the idr lookup
Right now, some functions use lid, ipc_addid() already uses idx as
the variable name.
seq: sequence number, to avoid quick collisions of the user space id
key: user space key, used for the rhash treeLink: http://lkml.kernel.org/r/20180712185241.4017-12-manfred@colorfullife.com
Signed-off-by: Manfred Spraul
Cc: Dmitry Vyukov
Cc: Davidlohr Bueso
Cc: Davidlohr Bueso
Cc: Herbert Xu
Cc: Kees Cook
Cc: Michael Kerrisk
Cc: Michal Hocko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Now that we know that rhashtable_init() will not fail, we can get rid of a
lot of the unnecessary cleanup paths when the call errored out.[manfred@colorfullife.com: variable name added to util.h to resolve checkpatch warning]
Link: http://lkml.kernel.org/r/20180712185241.4017-11-manfred@colorfullife.com
Signed-off-by: Davidlohr Bueso
Signed-off-by: Manfred Spraul
Cc: Dmitry Vyukov
Cc: Herbert Xu
Cc: Kees Cook
Cc: Michael Kerrisk
Cc: Michal Hocko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
In sysvipc we have an ids->tables_initialized regarding the rhashtable,
introduced in 0cfb6aee70bd ("ipc: optimize semget/shmget/msgget for lots
of keys")It's there, specifically, to prevent nil pointer dereferences, from using
an uninitialized api. Considering how rhashtable_init() can fail
(probably due to ENOMEM, if anything), this made the overall ipc
initialization capable of failure as well. That alone is ugly, but fine,
however I've spotted a few issues regarding the semantics of
tables_initialized (however unlikely they may be):- There is inconsistency in what we return to userspace: ipc_addid()
returns ENOSPC which is certainly _wrong_, while ipc_obtain_object_idr()
returns EINVAL.- After we started using rhashtables, ipc_findkey() can return nil upon
!tables_initialized, but the caller expects nil for when the ipc
structure isn't found, and can therefore call into ipcget() callbacks.Now that rhashtable initialization cannot fail, we can properly get rid of
the hack altogether.[manfred@colorfullife.com: commit id extended to 12 digits]
Link: http://lkml.kernel.org/r/20180712185241.4017-10-manfred@colorfullife.com
Signed-off-by: Davidlohr Bueso
Signed-off-by: Manfred Spraul
Cc: Dmitry Vyukov
Cc: Herbert Xu
Cc: Kees Cook
Cc: Michael Kerrisk
Cc: Michal Hocko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
rhashtable_init() may fail due to -ENOMEM, thus making the entire api
unusable. This patch removes this scenario, however unlikely. In order
to guarantee memory allocation, this patch always ends up doing
GFP_KERNEL|__GFP_NOFAIL for both the tbl as well as
alloc_bucket_spinlocks().Upon the first table allocation failure, we shrink the size to the
smallest value that makes sense and retry with __GFP_NOFAIL semantics.
With the defaults, this means that from 64 buckets, we retry with only 4.
Any later issues regarding performance due to collisions or larger table
resizing (when more memory becomes available) is the least of our
problems.Link: http://lkml.kernel.org/r/20180712185241.4017-9-manfred@colorfullife.com
Signed-off-by: Davidlohr Bueso
Signed-off-by: Manfred Spraul
Acked-by: Herbert Xu
Cc: Dmitry Vyukov
Cc: Kees Cook
Cc: Michael Kerrisk
Cc: Michal Hocko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
As of ce91f6ee5b3b ("mm: kvmalloc does not fallback to vmalloc for
incompatible gfp flags") we can simplify the caller and trust kvzalloc()
to just do the right thing. For the case of the GFP_ATOMIC context, we
can drop the __GFP_NORETRY flag for obvious reasons, and for the
__GFP_NOWARN case, however, it is changed such that the caller passes the
flag instead of making bucket_table_alloc() handle it.This slightly changes the gfp flags passed on to nested_table_alloc() as
it will now also use GFP_ATOMIC | __GFP_NOWARN. However, I consider this
a positive consequence as for the same reasons we want nowarn semantics in
bucket_table_alloc().[manfred@colorfullife.com: commit id extended to 12 digits, line wraps updated]
Link: http://lkml.kernel.org/r/20180712185241.4017-8-manfred@colorfullife.com
Signed-off-by: Davidlohr Bueso
Signed-off-by: Manfred Spraul
Acked-by: Michal Hocko
Cc: Dmitry Vyukov
Cc: Herbert Xu
Cc: Kees Cook
Cc: Michael Kerrisk
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
ipc/util.c contains multiple functions to get the ipc object pointer given
an id number.There are two sets of function: One set verifies the sequence counter part
of the id number, other functions do not check the sequence counter.The standard for function names in ipc/util.c is
- ..._check() functions verify the sequence counter
- ..._idr() functions do not verify the sequence counteripc_lock() is an exception: It does not verify the sequence counter value,
but this is not obvious from the function name.Furthermore, shm.c is the only user of this helper. Thus, we can simply
move the logic into shm_lock() and get rid of the function altogether.[manfred@colorfullife.com: most of changelog]
Link: http://lkml.kernel.org/r/20180712185241.4017-7-manfred@colorfullife.com
Signed-off-by: Davidlohr Bueso
Signed-off-by: Manfred Spraul
Cc: Dmitry Vyukov
Cc: Herbert Xu
Cc: Kees Cook
Cc: Michael Kerrisk
Cc: Michal Hocko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The comment that explains ipc_obtain_object_check is wrong: The function
checks the sequence number, not the reference counter.Note that checking the reference counter would be meaningless: The
reference counter is decreased without holding any locks, thus an object
with kern_ipc_perm.deleted=true may disappear at the end of the next rcu
grace period.Link: http://lkml.kernel.org/r/20180712185241.4017-6-manfred@colorfullife.com
Signed-off-by: Manfred Spraul
Reviewed-by: Davidlohr Bueso
Cc: Davidlohr Bueso
Cc: Dmitry Vyukov
Cc: Herbert Xu
Cc: Kees Cook
Cc: Michael Kerrisk
Cc: Michal Hocko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Both the comment and the name of ipcctl_pre_down_nolock() are misleading:
The function must be called while holdling the rw semaphore.Therefore the patch renames the function to ipcctl_obtain_check(): This
name matches the other names used in util.c:- "obtain" function look up a pointer in the idr, without
acquiring the object lock.
- The caller is responsible for locking.
- _check means that the sequence number is checked.Link: http://lkml.kernel.org/r/20180712185241.4017-5-manfred@colorfullife.com
Signed-off-by: Manfred Spraul
Reviewed-by: Davidlohr Bueso
Cc: Davidlohr Bueso
Cc: Dmitry Vyukov
Cc: Herbert Xu
Cc: Kees Cook
Cc: Michael Kerrisk
Cc: Michal Hocko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
ipc_addid() is impossible to use:
- for certain failures, the caller must not use ipc_rcu_putref(),
because the reference counter is not yet initialized.
- for other failures, the caller must use ipc_rcu_putref(),
because parallel operations could be ongoing already.The patch cleans that up, by initializing the refcount early, and by
modifying all callers.The issues is related to the finding of
syzbot+2827ef6b3385deb07eaf@syzkaller.appspotmail.com: syzbot found an
issue with reading kern_ipc_perm.seq, here both read and write to already
released memory could happen.Link: http://lkml.kernel.org/r/20180712185241.4017-4-manfred@colorfullife.com
Signed-off-by: Manfred Spraul
Cc: Dmitry Vyukov
Cc: Kees Cook
Cc: Davidlohr Bueso
Cc: Davidlohr Bueso
Cc: Herbert Xu
Cc: Michael Kerrisk
Cc: Michal Hocko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
ipc_addid() initializes kern_ipc_perm.seq after having called idr_alloc()
(within ipc_idr_alloc()).Thus a parallel semop() or msgrcv() that uses ipc_obtain_object_check()
may see an uninitialized value.The patch moves the initialization of kern_ipc_perm.seq before the calls
of idr_alloc().Notes:
1) This patch has a user space visible side effect:
If /proc/sys/kernel/*_next_id is used (i.e.: checkpoint/restore) and
if semget()/msgget()/shmget() fails in the final step of adding the id
to the rhash tree, then .._next_id is cleared. Before the patch, is
remained unmodified.There is no change of the behavior after a successful ..get() call: It
always clears .._next_id, there is no impact to non checkpoint/restore
code as that code does not use .._next_id.2) The patch correctly documents that after a call to ipc_idr_alloc(),
the full tear-down sequence must be used. The callers of ipc_addid()
do not fullfill that, i.e. more bugfixes are required.The patch is a squash of a patch from Dmitry and my own changes.
Link: http://lkml.kernel.org/r/20180712185241.4017-3-manfred@colorfullife.com
Reported-by: syzbot+2827ef6b3385deb07eaf@syzkaller.appspotmail.com
Signed-off-by: Manfred Spraul
Cc: Dmitry Vyukov
Cc: Kees Cook
Cc: Davidlohr Bueso
Cc: Michael Kerrisk
Cc: Davidlohr Bueso
Cc: Herbert Xu
Cc: Michal Hocko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
ipc_addid() initializes kern_ipc_perm.id after having called
ipc_idr_alloc().Thus a parallel semctl() or msgctl() that uses e.g. MSG_STAT may use this
unitialized value as the return code.The patch moves all accesses to kern_ipc_perm.id under the spin_lock().
The issues is related to the finding of
syzbot+2827ef6b3385deb07eaf@syzkaller.appspotmail.com: syzbot found an
issue with kern_ipc_perm.seqLink: http://lkml.kernel.org/r/20180712185241.4017-2-manfred@colorfullife.com
Signed-off-by: Manfred Spraul
Reviewed-by: Davidlohr Bueso
Cc: Dmitry Vyukov
Cc: Kees Cook
Cc: Davidlohr Bueso
Cc: Herbert Xu
Cc: Michael Kerrisk
Cc: Michal Hocko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The CHECKPOINT_RESTORE configuration option was introduced in 2012 and
combined with EXPERT. CHECKPOINT_RESTORE is already enabled in many
distribution kernels and also part of the defconfigs of various
architectures.To make it easier for distributions to enable CHECKPOINT_RESTORE this
removes EXPERT and moves the configuration option out of the EXPERT block.Link: http://lkml.kernel.org/r/20180712130733.11510-1-adrian@lisas.de
Signed-off-by: Adrian Reber
Acked-by: Oleg Nesterov
Reviewed-by: Hendrik Brueckner
Acked-by: Pavel Emelyanov
Cc: Eric W. Biederman
Cc: Andrei Vagin
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
get_seconds() is deprecated in favor of ktime_get_real_seconds(), which
returns a 64-bit timestamp.In the SYSV file system, the superblock timestamp is only 32 bits wide,
and it is used to check whether a file system is clean, so the best
solution seems to be to force a wraparound and explicitly convert it to an
unsigned 32-bit value.This is independent of the inode timestamps that are also 32-bit wide on
disk and that come from current_time().Link: http://lkml.kernel.org/r/20180713145236.3152513-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann
Acked-by: Thomas Gleixner
Reviewed-by: Andrew Morton
Cc: Alexander Viro
Cc: Christoph Hellwig
Cc: David Howells
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
We just truncate the seconds to 32-bit in one place now, so this can
trivially be converted over to using timespec64 consistently.Link: http://lkml.kernel.org/r/20180620100133.4035614-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann
Cc: Al Viro
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix a few typos/spellos in kernel/sysctl.c.
Link: http://lkml.kernel.org/r/bb09a8b9-f984-6dd4-b07b-3ecaf200862e@infradead.org
Signed-off-by: Randy Dunlap
Acked-by: Kees Cook
Cc: "Luis R. Rodriguez"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Pointer md is being assigned but is never used hence it is redundant and
can be removed.Cleans up clang warning:
warning: variable 'md' set but not used [-Wunused-but-set-variable]Link: http://lkml.kernel.org/r/20180711082346.5223-1-colin.king@canonical.com
Signed-off-by: Colin Ian King
Acked-by: Alexandre Bounine
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Before this change, if a multithreaded process forks while one of its
threads is changing a signal handler using sigaction(), the memcpy() in
copy_sighand() can race with the struct assignment in do_sigaction(). It
isn't clear whether this can cause corruption of the userspace signal
handler pointer, but it definitely can cause inconsistency between
different fields of struct sigaction.Take the appropriate spinlock to avoid this.
I have tested that this patch prevents inconsistency between sa_sigaction
and sa_flags, which is possible before this patch.Link: http://lkml.kernel.org/r/20180702145108.73189-1-jannh@google.com
Signed-off-by: Jann Horn
Acked-by: Michal Hocko
Reviewed-by: Andrew Morton
Cc: Rik van Riel
Cc: "Peter Zijlstra (Intel)"
Cc: Kees Cook
Cc: Oleg Nesterov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
make get_signal() already behaves like a boolean function. Let's actually
declare it as such too.Link: http://lkml.kernel.org/r/20180602103653.18181-18-christian@brauner.io
Signed-off-by: Christian Brauner
Reviewed-by: Andrew Morton
Cc: Al Viro
Cc: Eric W. Biederman
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: James Morris
Cc: Kees Cook
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Stephen Smalley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
sigkill_pending() already behaves like a boolean function. Let's actually
declare it as such too.Link: http://lkml.kernel.org/r/20180602103653.18181-17-christian@brauner.io
Signed-off-by: Christian Brauner
Reviewed-by: Andrew Morton
Cc: Al Viro
Cc: Eric W. Biederman
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: James Morris
Cc: Kees Cook
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Stephen Smalley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
legacy_queue() already behaves like a boolean function. Let's actually
declare it as such too.Link: http://lkml.kernel.org/r/20180602103653.18181-16-christian@brauner.io
Signed-off-by: Christian Brauner
Reviewed-by: Andrew Morton
Cc: Al Viro
Cc: Eric W. Biederman
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: James Morris
Cc: Kees Cook
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Stephen Smalley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
wants_signal() already behaves like a boolean function. Let's actually
declare it as such too.Link: http://lkml.kernel.org/r/20180602103653.18181-15-christian@brauner.io
Signed-off-by: Christian Brauner
Reviewed-by: Andrew Morton
Cc: Al Viro
Cc: Eric W. Biederman
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: James Morris
Cc: Kees Cook
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Stephen Smalley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The return value of flush_sigqueue_mask() is never checked anywhere.
Link: http://lkml.kernel.org/r/20180602103653.18181-14-christian@brauner.io
Signed-off-by: Christian Brauner
Reviewed-by: Andrew Morton
Cc: Al Viro
Cc: Eric W. Biederman
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: James Morris
Cc: Kees Cook
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Stephen Smalley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
unhandled_signal() already behaves like a boolean function. Let's
actually declare it as such too. All callers treat it as such too.Link: http://lkml.kernel.org/r/20180602103653.18181-13-christian@brauner.io
Signed-off-by: Christian Brauner
Reviewed-by: Andrew Morton
Cc: Al Viro
Cc: Eric W. Biederman
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: James Morris
Cc: Kees Cook
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Stephen Smalley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
recalc_sigpending_tsk() already behaves like a boolean function. Let's
actually declare it as such too.Link: http://lkml.kernel.org/r/20180602103653.18181-12-christian@brauner.io
Signed-off-by: Christian Brauner
Reviewed-by: Andrew Morton
Cc: Al Viro
Cc: Eric W. Biederman
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: James Morris
Cc: Kees Cook
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Stephen Smalley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
has_pending_signals() already behaves like a boolean function. Let's
actually declare it as such too.Link: http://lkml.kernel.org/r/20180602103653.18181-11-christian@brauner.io
Signed-off-by: Christian Brauner
Reviewed-by: Andrew Morton
Cc: Al Viro
Cc: Eric W. Biederman
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: James Morris
Cc: Kees Cook
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Stephen Smalley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
sig_ignored() already behaves like a boolean function. Let's actually
declare it as such too.Link: http://lkml.kernel.org/r/20180602103653.18181-10-christian@brauner.io
Signed-off-by: Christian Brauner
Reviewed-by: Andrew Morton
Cc: Al Viro
Cc: Eric W. Biederman
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: James Morris
Cc: Kees Cook
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Stephen Smalley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
sig_task_ignored() already behaves like a boolean function. Let's
actually declare it as such too.Link: http://lkml.kernel.org/r/20180602103653.18181-9-christian@brauner.io
Signed-off-by: Christian Brauner
Reviewed-by: Andrew Morton
Cc: Al Viro
Cc: Eric W. Biederman
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: James Morris
Cc: Kees Cook
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Stephen Smalley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
sig_handler_ignored() already behaves like a boolean function. Let's
actually declare it as such too.Link: http://lkml.kernel.org/r/20180602103653.18181-8-christian@brauner.io
Signed-off-by: Christian Brauner
Reviewed-by: Andrew Morton
Cc: Al Viro
Cc: Eric W. Biederman
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: James Morris
Cc: Kees Cook
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Stephen Smalley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
kill_ok_by_cred() already behaves like a boolean function. Let's actually
declare it as such too.Link: http://lkml.kernel.org/r/20180602103653.18181-7-christian@brauner.io
Signed-off-by: Christian Brauner
Reviewed-by: Andrew Morton
Cc: Al Viro
Cc: Eric W. Biederman
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: James Morris
Cc: Kees Cook
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Stephen Smalley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The goto is not needed and does not add any clarity. Simply return
-EINVAL on unexpected sigset_t struct size directly.Link: http://lkml.kernel.org/r/20180602103653.18181-6-christian@brauner.io
Signed-off-by: Christian Brauner
Acked-by: Oleg Nesterov
Reviewed-by: Andrew Morton
Cc: Al Viro
Cc: Eric W. Biederman
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: James Morris
Cc: Kees Cook
Cc: Peter Zijlstra
Cc: Stephen Smalley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
do_sigpending() returned 0 unconditionally so it doesn't make sense to
have it return at all. This allows us to simplify a bunch of syscall
callers.Link: http://lkml.kernel.org/r/20180602103653.18181-5-christian@brauner.io
Signed-off-by: Christian Brauner
Acked-by: Al Viro
Acked-by: Oleg Nesterov
Reviewed-by: Andrew Morton
Cc: Eric W. Biederman
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: James Morris
Cc: Kees Cook
Cc: Peter Zijlstra
Cc: Stephen Smalley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
may_ptrace_stop() already behaves like a boolean function. Let's actually
declare it as such too.Link: http://lkml.kernel.org/r/20180602103653.18181-4-christian@brauner.io
Signed-off-by: Christian Brauner
Reviewed-by: Andrew Morton
Cc: Al Viro
Cc: Eric W. Biederman
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: James Morris
Cc: Kees Cook
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Stephen Smalley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
kill_as_cred_perm() already behaves like a boolean function. Let's
actually declare it as such too.Link: http://lkml.kernel.org/r/20180602103653.18181-3-christian@brauner.io
Signed-off-by: Christian Brauner
Reviewed-by: Andrew Morton
Cc: Al Viro
Cc: Eric W. Biederman
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: James Morris
Cc: Kees Cook
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Stephen Smalley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Patch series "signal: refactor some functions", v3.
This series refactors a bunch of functions in signal.c to simplify parts
of the code.The greatest single change is declaring the static do_sigpending() helper
as void which makes it possible to remove a bunch of unnecessary checks in
the syscalls later on.This patch (of 17):
force_sigsegv() returned 0 unconditionally so it doesn't make sense to have
it return at all. In addition, there are no callers that check
force_sigsegv()'s return value.Link: http://lkml.kernel.org/r/20180602103653.18181-2-christian@brauner.io
Signed-off-by: Christian Brauner
Reviewed-by: Andrew Morton
Cc: Eric W. Biederman
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: James Morris
Cc: Kees Cook
Cc: Peter Zijlstra
Cc: Stephen Smalley
Cc: Al Viro
Cc: Oleg Nesterov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Now that we pass down 64-bit timestamps from VFS, we just need to convert
that correctly into on-disk timestamps. To make that work correctly, this
changes the last use of time_to_tm() in the kernel to time64_to_tm(),
which also lets use remove that deprecated interfaces.Similarly, the time_t use in fat_time_fat2unix() truncates the timestamp
on the way in, which can be avoided by using types that are wide enough to
hold the intermediate values during the conversion.[hirofumi@mail.parknet.co.jp: remove useless temporary variable, needless long long]
Link: http://lkml.kernel.org/r/20180619153646.3637529-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann
Acked-by: OGAWA Hirofumi
Cc: Jeff Layton
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
On corrupted FATfs may have invalid ->i_start. To handle it, this checks
->i_start before using, and return proper error code.Link: http://lkml.kernel.org/r/87o9f8y1t5.fsf_-_@mail.parknet.co.jp
Signed-off-by: OGAWA Hirofumi
Reported-by: Anatoly Trosinenko
Tested-by: Anatoly Trosinenko
Cc: Alan Cox
Cc: Al Viro
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Add FITRIM ioctl for FAT file system
[witallwang@gmail.com: use u64s]
Link: http://lkml.kernel.org/r/87h8l37hub.fsf@mail.parknet.co.jp
[hirofumi@mail.parknet.co.jp: bug fixes, coding style fixes, add signal check]
Link: http://lkml.kernel.org/r/87fu10anhj.fsf@mail.parknet.co.jp
Signed-off-by: Wentao Wang
Signed-off-by: OGAWA Hirofumi
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This fixes the following issues:
- When a buffer size is supplied to reiserfs_listxattr() such that each
individual name fits, but the concatenation of all names doesn't fit,
reiserfs_listxattr() overflows the supplied buffer. This leads to a
kernel heap overflow (verified using KASAN) followed by an out-of-bounds
usercopy and is therefore a security bug.- When a buffer size is supplied to reiserfs_listxattr() such that a
name doesn't fit, -ERANGE should be returned. But reiserfs instead just
truncates the list of names; I have verified that if the only xattr on a
file has a longer name than the supplied buffer length, listxattr()
incorrectly returns zero.With my patch applied, -ERANGE is returned in both cases and the memory
corruption doesn't happen anymore.Credit for making me clean this code up a bit goes to Al Viro, who pointed
out that the ->actor calling convention is suboptimal and should be
changed.Link: http://lkml.kernel.org/r/20180802151539.5373-1-jannh@google.com
Fixes: 48b32a3553a5 ("reiserfs: use generic xattr handlers")
Signed-off-by: Jann Horn
Acked-by: Jeff Mahoney
Cc: Eric Biggers
Cc: Al Viro
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This uses the deprecated time_t type but is write-only, and could be
removed, but as Jeff explains, having a timestamp can be usefule for
post-mortem analysis in crash dumps.In order to remove one of the last instances of time_t, this changes the
type to time64_t, same as j_trans_start_time.Link: http://lkml.kernel.org/r/20180622133315.221210-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann
Cc: Jan Kara
Cc: Jeff Mahoney
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Before linux-2.4.6, print_time() was used to pretty-print an inode time
when running reiserfs in user space, after that it has become obsolete and
is still a bit incorrect: It behaves differently on 32-bit and 64-bit
machines, and uses a static buffer to hold a string, which could lead to
undefined behavior if we ever called this from multiple places
simultaneously.Since we always want to treat the timestamps as 'unsigned' anyway, simply
printing them as an integer is both simpler and safer while avoiding the
deprecated time_t type.Link: http://lkml.kernel.org/r/20180620142522.27639-3-arnd@arndb.de
Signed-off-by: Arnd Bergmann
Reviewed-by: Jan Kara
Cc: Al Viro
Cc: Jeff Mahoney
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
