The first patch in the series is essential - it is the one fixing
the bug. Other patches accumulated while chasing the bug.
For a detailed explanation see the commit messages of first patch.
https://jira.vzint.dev/browse/PSBM-151029
Alexander Atanasov (3):
ve/userns: remove all hashed entries b
user_namespaces_init was converted from module_init
to subsys_initcall which is called at later point.
init_user_ns is used before that call in sget(...).
So move the initialization of ucount_max into the
declaration of init_user_ns.
https://jira.vzint.dev/browse/PSBM-151029
Signed-off-by: Alexand
From: Li Rongqing
msgctl10 of ltp triggers the following lockup When CONFIG_KASAN is
enabled on large memory SMP systems, the pages initialization can take a
long time, if msgctl10 requests a huge block memory, and it will block
rcu scheduler, so release cpu actively.
After adding schedule() in
548df8b4b57b (ve/userns: associate user_struct with the user_namespace,
2017-03-13)
introduced dynamically allocated per-userns uid hastable
instead of using a global static hash table.
The problem with that allocate hashtable is that life cycle of
the two objects is different - both structes use
This is based on different commits from newer kernel versions.
https://jira.vzint.dev/browse/PSBM-151029
Signed-off-by: Alexander Atanasov
---
include/linux/list.h | 51 +++-
1 file changed, 27 insertions(+), 24 deletions(-)
diff --git a/include/linux/lis
From: Francesco Ruggeri
If a non zero value happens to be in xt[NFPROTO_BRIDGE].cur at init
time, the following panic can be caused by running
% ebtables -t broute -F BROUTING
from a 32-bit user level on a 64-bit kernel. This patch replaces
kmalloc_array with kcalloc when allocating xt.
[ 474
From: Kees Cook
Andreas Christoforou reported:
UBSAN: Undefined behaviour in ipc/mqueue.c:414:49 signed integer overflow:
9 * 2305843009213693951 cannot be represented in type 'long int'
...
Call Trace:
mqueue_evict_inode+0x8e7/0xa10 ipc/mqueue.c:414
evict+0x472/0x8c0 fs/inode.c:
Use correct lock to protect the kill_requests operation on all request
queues. Test of the FUSE_S_FAIL_IMMEDIATELY bit needs to be done with
corresponding lock to prevent new requests being added to a queue after
it has been killed.
Adjust the order of queues that kill_request operation is perform
