Input: i8042 - add Fujitsu Lifebook UH554 to nomux/notimeout list
Similar to AH544, without these quirks, the touchpad is not responsive
on this product. Add it to the nomux/notimeout list alongside other
similar Fujitsu laptops.
kernel/relay.c: handle alloc_percpu returning NULL in relay_open
alloc_percpu() may return NULL, which means chan->buf may be set to NULL.
In that case, when we do *per_cpu_ptr(chan->buf, ...), we dereference an
invalid pointer:
BUG: Unable to handle kernel data access at 0x7dae0000
Faulting instruction address: 0xc0000000003f3fec
...
NIP relay_open+0x29c/0x600
LR relay_open+0x270/0x600
Call Trace:
relay_open+0x264/0x600 (unreliable)
__blk_trace_setup+0x254/0x600
blk_trace_setup+0x68/0xa0
sg_ioctl+0x7bc/0x2e80
do_vfs_ioctl+0x13c/0x1300
ksys_ioctl+0x94/0x130
sys_ioctl+0x48/0xb0
system_call+0x5c/0x68
Check if alloc_percpu returns NULL.
This was found by syzkaller both on x86 and powerpc, and the reproducer
it found on powerpc is capable of hitting the issue as an unprivileged
user.
Fixes: 017c59c042d0 ("relay: Use per CPU constructs for the relay channel buffer pointers")
Reported-by: <email address hidden>
Reported-by: <email address hidden>
Reported-by: <email address hidden>
Reported-by: <email address hidden>
Signed-off-by: Daniel Axtens <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Reviewed-by: Michael Ellerman <email address hidden>
Reviewed-by: Andrew Donnellan <email address hidden>
Acked-by: David Rientjes <email address hidden>
Cc: Akash Goel <email address hidden>
Cc: Andrew Donnellan <email address hidden>
Cc: Guenter Roeck <email address hidden>
Cc: Salvatore Bonaccorso <email address hidden>
Cc: <email address hidden> [4.10+]
Link: http://<email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
(cherry picked from commit 54e200ab40fc14c863bcc80a51e20b7906608fce)
CVE-2019-19642
Signed-off-by: Benjamin M Romer <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
20521da...
by
Navid Emamdoost <email address hidden>
UBUNTU: SAUCE: nbd_genl_status: null check for nla_nest_start
CVE-2019-16089
nla_nest_start may fail and return NULL. The check is inserted, and
errno is selected based on other call sites within the same source code.
Update: removed extra new line.
v3 Update: added release reply, thanks to Michal Kubecek for pointing
out.
Signed-off-by: Navid Emamdoost <email address hidden>
Reviewed-by: Michal Kubecek <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Acked-by: Marcelo Henrique Cerri <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
The 'struct inode.i_readcount' field is maintained at the VFS, and
should not be modified by filesystems. But aufs does in one place,
which causes it to be unbalanced.
This started with Linux v2.6.39 commit 890275b5eb79 ("IMA: maintain
i_readcount in the VFS layer"), which moved the i_readcount updates
from IMA into the VFS (at the same places IMA was called previously)
and introduced 'mutex_lock(i_mutex)' in the ima_file_check() path.
The former change is functionally equivalent, thus no changes are
needed in response to it.
The latter change, on the other hand, is _not_; and is reported to
cause a deadlock in aufs (see below), thus it dropped the call to
ima_file_check().
However, when dropping the ima_file_check() call, aufs introduced
the i_readcount_inc() call as well, which according to the commit
changes is not necessary.
This can be observed in aufs2-standalone.git commit 1dbd1c864e455
("aufs2.1 standalone version for linux-2.6."), announced to the
aufs-users mailing list on 2011-04-04 [1].
diff --git a/ChangeLog b/ChangeLog
...
+commit 17eac367b03334e57a93e8051eb712add24d2534
+Author: J. R. Okajima <email address hidden>
+Date: Fri Apr 1 16:31:22 2011 +0900
+
+ aufs: for 2.6.39, limit the support for IMA
+
+ Since it acquires i_mutex and causes a deadlock, replace a
+ ima_file_check() call by i_readcount_inc().
+
+ Signed-off-by: J. R. Okajima <email address hidden>
...
diff --git a/fs/aufs/vfsub.c b/fs/aufs/vfsub.c
...
struct file *vfsub_dentry_open(struct path *path, int flags)
...
+ if (!IS_ERR_OR_NULL(file)
+ && (file->f_mode & (FMODE_READ | FMODE_WRITE)) == FMODE_READ)
+ i_readcount_inc(path->dentry->d_inode);
Apparently, this might have been a misunderstanding of one hunk in
the 2.6.39 commit, that deletes the lines to increment i_readcount,
and adds the lines to acquire i_mutex.
It reuses code from the removed function ima_counts_get() to create
ima_rdwr_violation_check(), and another hunk calls the new function
from ima_file_check(). But note that the i_readcount increment was
_not_ called from ima_file_check() previously, via ima_counts_get():
#@@ -318,6 +308,7 @@ int ima_file_check(struct file *file, int mask)
...
+ ima_rdwr_violation_check(file);
So, in order to avoid the unbalance caused to i_readcount, drop the
i_readcount_inc() call.
Note the issue is not the lack of a corresponding i_readcount_dec()
call; it's the mere usage of these functions outside of VFS layer,
where i_readcount is maintained.
When running with conntrack rules, the dropped overlap fragments may cause
EPERM to be returned to sendto. Instead of completely failing, just ignore
those errors and continue. If this causes packets with overlap fragments to
be dropped as expected, that is okay. And if it causes packets that are
expected to be received to be dropped, which should not happen, it will be
detected as failure.
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit 065fcfd49763ec71ae345bb5c5a74f961031e70e)
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Sultan Alsawaf <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>
Like other vectors already patched, this one here allows the root user
to load ACPI tables, which enables arbitrary physical address writes,
which in turn makes it possible to disable lockdown. This patch prevents
this by checking the lockdown status before allowing a new ACPI table to be
installed. The link in the trailer shows a PoC of how this might be
used.
