Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
commit 80ad406dc1f29f1e6924b5c850c614168abcf081
Author: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Date: Tue Oct 10 08:56:58 2017 -0300
UBUNTU: Ubuntu-4.4.0-98.121
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit c8f09013b02fc4f19916a7d429014718adf4e53b
Author: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Date: Wed Sep 27 17:23:49 2017 -0300
UBUNTU: d/s/m/insert-ubuntu-changes: use full version numbers
Ignore: yes
Make insert-ubuntu-changes to consider full version numbers when looping
through debian.master/changelog entries and comparing the version number
of each entry with the arguments passed to the script to decide which
entries should be included in the output changelog file.
Previously, only the last number in the version was used in this
comparison. For example, when comparing 4.4.0-50.51 and 4.4.0-83.84 only
the numbers 51 and 84 were actually used in the comparison. That however
might not work properly when the major version is bumped.
For instance, using "end" as 4.4.0-50.51 and "start" as 4.4.0-83.84 used
to work fine because 84 is greater than 51. However when using "end"
as 4.11.0-10.11 and "start" as 4.13.0-2.3, no entry was being selected
since 3 is not greater than 11.
Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 6c4fa18da50ecc184055e56a0acfe74942081b3c
Author: Yadan Fan <ydfan@suse.com>
Date: Fri Oct 6 16:32:58 2017 -0400
scsi: hpsa: limit transfer length to 1MB
BugLink: https://bugs.launchpad.net/bugs/1720359
The hpsa firmware will bypass the cache for any request larger than 1MB,
so we should cap the request size to avoid any performance degradation
in kernels later than v4.3
This degradation is caused from d2be537c3ba3568acd79cd178327b842e60d035e,
which changed max_sectors_kb to 1280k, but the hardware is able to work
fine with it, so the true fix should be from hpsa driver.
Signed-off-by: Yadan Fan <ydfan@suse.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Acked-by: Don Brace <don.brace@microsemi.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit e2c7b433f729cedb32514480af8cbdf2fe5cf264)
Signed-off-by: Eric Desrochers <eric.desrochers@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 688c168ef8fd7d5a140864aadb50f8f23a0a0fe0
Author: hayeswang <hayeswang@realtek.com>
Date: Thu Oct 5 10:19:22 2017 +0800
r8152: fix the list rx_done may be used without initialization
BugLink: http://bugs.launchpad.net/bugs/1720977
The list rx_done would be initialized when the linking on occurs.
Therefore, if a napi is scheduled without any linking on before,
the following kernel panic would happen.
BUG: unable to handle kernel NULL pointer dereference at 000000000000008
IP: [<ffffffffc085efde>] r8152_poll+0xe1e/0x1210 [r8152]
PGD 0
Oops: 0002 [#1] SMP
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 98d068ab52b4b11d403995ed14154660797e7136)
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Acked-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit e8ddfc4680cdfba5ba20579fa8f504570583fd4c
Author: Vinson Lee <vlee@freedesktop.org>
Date: Fri Sep 29 22:42:52 2017 +0000
UBUNTU: d-i: Add bnxt_en to nic-modules.
BugLink: http://bugs.launchpad.net/bugs/1720466
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 1ab5e52e52437c3ed12ceeb6d8c4198e5b767450
Author: Paolo Pisati <paolo.pisati@canonical.com>
Date: Fri Sep 22 11:11:57 2017 +0200
UBUNTU: snapcraft.yaml: add dpkg-dev to the build deps
BugLink: http://bugs.launchpad.net/bugs/1718886
Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 17b4c108e3eabb5ab5bb3f407725d2cac731c2e1
Author: Weifeng Voon <weifeng.voon@intel.com>
Date: Thu Sep 21 13:03:57 2017 +0800
i2c: designware: Use transfer timeout from ioctl I2C_TIMEOUT
BugLink: https://bugs.launchpad.net/bugs/1718578
This allows applications to set the transfer timeout in 10ms increments via
ioctl I2C_TIMEOUT.
Signed-off-by: Weifeng Voon <weifeng.voon@intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
(cherry picked from commit d0bcd8df9aea2bcdbfcb074d408bdc7136031bc5)
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Shrirang Bagul <shrirang.bagul@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 63b70075e5005762da11c975d3900e9997cd70ae
Author: Ewan D. Milne <emilne@redhat.com>
Date: Wed Sep 20 15:12:56 2017 -0400
scsi: ses: Fix SAS device detection in enclosure
BugLink: http://bugs.launchpad.net/bugs/1693369
The call to scsi_is_sas_rphy() needs to be made on the SAS end_device,
not on the SCSI device.
Fixes: 835831c57e9b ("ses: use scsi_is_sas_rphy instead of is_sas_attached")
Signed-off-by: Ewan D. Milne <emilne@redhat.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(back ported from commit 9373eba6cfae48911b977d14323032cd5d161aae)
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 908c4745b591ea3e545a74e44a5c176a599054e3
Author: Johannes Thumshirn <jthumshirn@suse.de>
Date: Wed Sep 20 15:12:55 2017 -0400
scsi: sas: provide stub implementation for scsi_is_sas_rphy
BugLink: http://bugs.launchpad.net/bugs/1693369
Provide a stub implementation for scsi_is_sas_rphy for kernel
configurations which do not have CONFIG_SCSI_SAS_ATTRS defined.
Reported-by: kbuild test robot <lkp@intel.com>
Suggested-by: James Bottomley <jejb@linux.vnet.ibm.com>
Reviewed-by: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(back ported from commit c1a23f6d64552b4480208aa584ec7e9c13d6d9c3)
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 19a501eec44c3ed9525b3b6991a21a83d702ecd4
Author: James Bottomley <James.Bottomley@HansenPartnership.com>
Date: Wed Sep 20 15:12:54 2017 -0400
ses: fix discovery of SATA devices in SAS enclosures
BugLink: http://bugs.launchpad.net/bugs/1693369
The current discovery routines use the VPD 0x83 inquiry page to find
the device SAS address and match it to the end point in the enclosure.
This doesn't work for SATA devices because expanders (or hosts) simply
make up an endpoint address for STP and thus the address returned by
the VPD page never matches. Instead of doing this, for SAS attached
devices, match by the direct endpoint address instead.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
(cherry picked from commit 3f8d6f2a0797e8c650a47e5c1b5c2601a46f4293)
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit ec384fb9948065e0e1b84d9ecaebda228a590816
Author: James Bottomley <James.Bottomley@HansenPartnership.com>
Date: Wed Sep 20 15:12:53 2017 -0400
scsi_transport_sas: add function to get SAS endpoint address
BugLink: http://bugs.launchpad.net/bugs/1693369
For a device known to be SAS connected, this will return the endpoint
address. This is useful for getting the SAS address of SATA devices.
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
(cherry picked from commit bcf508c13385e74972f5cc06d8471d5c100395b0)
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 6a03f9bee206347b812585ef5737f1eae6ae1a89
Author: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Date: Wed Sep 20 11:55:28 2017 -0300
fs: aio: fix the increment of aio-nr and counting against aio-max-nr
BugLink: http://bugs.launchpad.net/bugs/1718397
Currently, aio-nr is incremented in steps of 'num_possible_cpus() * 8'
for io_setup(nr_events, ..) with 'nr_events < num_possible_cpus() * 4':
ioctx_alloc()
...
nr_events = max(nr_events, num_possible_cpus() * 4);
nr_events *= 2;
...
ctx->max_reqs = nr_events;
...
aio_nr += ctx->max_reqs;
....
This limits the number of aio contexts actually available to much less
than aio-max-nr, and is increasingly worse with greater number of CPUs.
For example, with 64 CPUs, only 256 aio contexts are actually available
(with aio-max-nr = 65536) because the increment is 512 in that scenario.
Note: 65536 [max aio contexts] / (64*4*2) [increment per aio context]
is 128, but make it 256 (double) as counting against 'aio-max-nr * 2':
ioctx_alloc()
...
if (aio_nr + nr_events > (aio_max_nr * 2UL) ||
...
goto err_ctx;
...
This patch uses the original value of nr_events (from userspace) to
increment aio-nr and count against aio-max-nr, which resolves those.
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Reported-by: Lekshmi C. Pillai <lekshmi.cpillai@in.ibm.com>
Tested-by: Lekshmi C. Pillai <lekshmi.cpillai@in.ibm.com>
Tested-by: Paul Nguyen <nguyenp@us.ibm.com>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
(cherry picked from commit 2a8a98673c13cb2a61a6476153acf8344adfa992)
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 66a7f616d2cc10fc526b92ce2ee5bcbb911ded54
Author: Shrirang Bagul <shrirang.bagul@canonical.com>
Date: Thu Oct 5 15:45:01 2017 +0800
UBUNTU: SAUCE: USB: serial: qcserial: add Dell DW5818, DW5819
BugLink: http://bugs.launchpad.net/bugs/1721455
Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
series which will by default boot with vid 0x413c and pid's 0x81cf,
0x81d0, 0x81d1,0x81d2.
Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit cbfc1a9519f86210fc84dbb90b49b8d23a2e92a9
Author: Jan Beulich <jbeulich@suse.com>
Date: Thu Oct 5 16:31:25 2017 +0800
xen-blkback: don't leak stack data via response ring
Rather than constructing a local structure instance on the stack, fill
the fields directly on the shared ring, just like other backends do.
Build on the fact that all response structure flavors are actually
identical (the old code did make this assumption too).
This is XSA-216.
Cc: stable@vger.kernel.org
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CVE-2017-10911
(backported from commit 089bc0143f489bd3a4578bdff5f4ca68fb26f341)
Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 643be1b19d3fccb9bfaa43dac91b31de0f4752e2
Author: Tyler Hicks <tyhicks@canonical.com>
Date: Fri Oct 6 04:43:49 2017 +0000
seccomp: Action to log before allowing
BugLink: https://launchpad.net/bugs/1567597
Add a new action, SECCOMP_RET_LOG, that logs a syscall before allowing
the syscall. At the implementation level, this action is identical to
the existing SECCOMP_RET_ALLOW action. However, it can be very useful when
initially developing a seccomp filter for an application. The developer
can set the default action to be SECCOMP_RET_LOG, maybe mark any
obviously needed syscalls with SECCOMP_RET_ALLOW, and then put the
application through its paces. A list of syscalls that triggered the
default action (SECCOMP_RET_LOG) can be easily gleaned from the logs and
that list can be used to build the syscall whitelist. Finally, the
developer can change the default action to the desired value.
This provides a more friendly experience than seeing the application get
killed, then updating the filter and rebuilding the app, seeing the
application get killed due to a different syscall, then updating the
filter and rebuilding the app, etc.
The functionality is similar to what's supported by the various LSMs.
SELinux has permissive mode, AppArmor has complain mode, SMACK has
bring-up mode, etc.
SECCOMP_RET_LOG is given a lower value than SECCOMP_RET_ALLOW as allow
while logging is slightly more restrictive than quietly allowing.
Unfortunately, the tests added for SECCOMP_RET_LOG are not capable of
inspecting the audit log to verify that the syscall was logged.
With this patch, the logic for deciding if an action will be logged is:
if action == RET_ALLOW:
do not log
else if action == RET_KILL && RET_KILL in actions_logged:
log
else if action == RET_LOG && RET_LOG in actions_logged:
log
else if filter-requests-logging && action in actions_logged:
log
else if audit_enabled && process-is-being-audited:
log
else:
do not log
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
(backported from commit 59f5cf44a38284eb9e76270c786fb6cc62ef8ac4)
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 854381716daaa1a9fe488c979b29502260f4ce6a
Author: Tyler Hicks <tyhicks@canonical.com>
Date: Fri Oct 6 04:43:48 2017 +0000
seccomp: Filter flag to log all actions except SECCOMP_RET_ALLOW
BugLink: https://launchpad.net/bugs/1721676
Add a new filter flag, SECCOMP_FILTER_FLAG_LOG, that enables logging for
all actions except for SECCOMP_RET_ALLOW for the given filter.
SECCOMP_RET_KILL actions are always logged, when "kill" is in the
actions_logged sysctl, and SECCOMP_RET_ALLOW actions are never logged,
regardless of this flag.
This flag can be used to create noisy filters that result in all
non-allowed actions to be logged. A process may have one noisy filter,
which is loaded with this flag, as well as a quiet filter that's not
loaded with this flag. This allows for the actions in a set of filters
to be selectively conveyed to the admin.
Since a system could have a large number of allocated seccomp_filter
structs, struct packing was taken in consideration. On 64 bit x86, the
new log member takes up one byte of an existing four byte hole in the
struct. On 32 bit x86, the new log member creates a new four byte hole
(unavoidable) and consumes one of those bytes.
Unfortunately, the tests added for SECCOMP_FILTER_FLAG_LOG are not
capable of inspecting the audit log to verify that the actions taken in
the filter were logged.
With this patch, the logic for deciding if an action will be logged is:
if action == RET_ALLOW:
do not log
else if action == RET_KILL && RET_KILL in actions_logged:
log
else if filter-requests-logging && action in actions_logged:
log
else if audit_enabled && process-is-being-audited:
log
else:
do not log
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
(backported from commit e66a39977985b1e69e17c4042cb290768eca9b02)
[tyhicks: disabled ability to log SECCOMP_RET_TRACE due to code changes]
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 893f00af1f5d12e17b2a41dcfdaa4498855954a1
Author: Tyler Hicks <tyhicks@canonical.com>
Date: Fri Oct 6 04:43:47 2017 +0000
seccomp: Selftest for detection of filter flag support
BugLink: https://launchpad.net/bugs/1721676
BugLink: https://launchpad.net/bugs/1567597
Userspace needs to be able to reliably detect the support of a filter
flag. A good way of doing that is by attempting to enter filter mode,
with the flag bit(s) in question set, and a NULL pointer for the args
parameter of seccomp(2). EFAULT indicates that the flag is valid and
EINVAL indicates that the flag is invalid.
This patch adds a selftest that can be used to test this method of
detection in userspace.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit 2b7ea5b5b5799f2878ed454bb48032bed6d101d3)
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit c8a22a5f2af9b6484b9730e8ef5ced834d15d803
Author: Tyler Hicks <tyhicks@canonical.com>
Date: Fri Oct 6 04:43:46 2017 +0000
seccomp: Sysctl to configure actions that are allowed to be logged
BugLink: https://launchpad.net/bugs/1721676
BugLink: https://launchpad.net/bugs/1567597
Adminstrators can write to this sysctl to set the seccomp actions that
are allowed to be logged. Any actions not found in this sysctl will not
be logged.
For example, all SECCOMP_RET_KILL, SECCOMP_RET_TRAP, and
SECCOMP_RET_ERRNO actions would be loggable if "kill trap errno" were
written to the sysctl. SECCOMP_RET_TRACE actions would not be logged
since its string representation ("trace") wasn't present in the sysctl
value.
The path to the sysctl is:
/proc/sys/kernel/seccomp/actions_logged
The actions_avail sysctl can be read to discover the valid action names
that can be written to the actions_logged sysctl with the exception of
"allow". SECCOMP_RET_ALLOW actions cannot be configured for logging.
The default setting for the sysctl is to allow all actions to be logged
except SECCOMP_RET_ALLOW. While only SECCOMP_RET_KILL actions are
currently logged, an upcoming patch will allow applications to request
additional actions to be logged.
There's one important exception to this sysctl. If a task is
specifically being audited, meaning that an audit context has been
allocated for the task, seccomp will log all actions other than
SECCOMP_RET_ALLOW despite the value of actions_logged. This exception
preserves the existing auditing behavior of tasks with an allocated
audit context.
With this patch, the logic for deciding if an action will be logged is:
if action == RET_ALLOW:
do not log
else if action == RET_KILL && RET_KILL in actions_logged:
log
else if audit_enabled && task-is-being-audited:
log
else:
do not log
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
(backported from commit 0ddec0fc8900201c0897b87b762b7c420436662f)
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 4ae31a2fb2f5c8a810887ab6e1e0226fb478aaf7
Author: Tyler Hicks <tyhicks@canonical.com>
Date: Fri Oct 6 04:43:45 2017 +0000
seccomp: Operation for checking if an action is available
BugLink: https://launchpad.net/bugs/1721676
BugLink: https://launchpad.net/bugs/1567597
Userspace code that needs to check if the kernel supports a given action
may not be able to use the /proc/sys/kernel/seccomp/actions_avail
sysctl. The process may be running in a sandbox and, therefore,
sufficient filesystem access may not be available. This patch adds an
operation to the seccomp(2) syscall that allows userspace code to ask
the kernel if a given action is available.
If the action is supported by the kernel, 0 is returned. If the action
is not supported by the kernel, -1 is returned with errno set to
-EOPNOTSUPP. If this check is attempted on a kernel that doesn't support
this new operation, -1 is returned with errno set to -EINVAL meaning
that userspace code will have the ability to differentiate between the
two error cases.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Suggested-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Kees Cook <keescook@chromium.org>
(backported from commit d612b1fd8010d0d67b5287fe146b8b55bcbb8655)
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit aac883e7a2c96921e885b43db10fa1a70b624a39
Author: Tyler Hicks <tyhicks@canonical.com>
Date: Fri Oct 6 04:43:44 2017 +0000
seccomp: Sysctl to display available actions
BugLink: https://launchpad.net/bugs/1721676
BugLink: https://launchpad.net/bugs/1567597
This patch creates a read-only sysctl containing an ordered list of
seccomp actions that the kernel supports. The ordering, from left to
right, is the lowest action value (kill) to the highest action value
(allow). Currently, a read of the sysctl file would return "kill trap
errno trace allow". The contents of this sysctl file can be useful for
userspace code as well as the system administrator.
The path to the sysctl is:
/proc/sys/kernel/seccomp/actions_avail
libseccomp and other userspace code can easily determine which actions
the current kernel supports. The set of actions supported by the current
kernel may be different than the set of action macros found in kernel
headers that were installed where the userspace code was built.
In addition, this sysctl will allow system administrators to know which
actions are supported by the kernel and make it easier to configure
exactly what seccomp logs through the audit subsystem. Support for this
level of logging configuration will come in a future patch.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
(backported from commit 8e5f1ad116df6b0de65eac458d5e7c318d1c05af)
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 806b808512d66cbce45068ce5bb47d76d52ced94
Author: Kees Cook <keescook@chromium.org>
Date: Fri Oct 6 04:43:43 2017 +0000
seccomp: Provide matching filter for introspection
BugLink: https://launchpad.net/bugs/1721676
BugLink: https://launchpad.net/bugs/1567597
Both the upcoming logging improvements and changes to RET_KILL will need
to know which filter a given seccomp return value originated from. In
order to delay logic processing of result until after the seccomp loop,
this adds a single pointer assignment on matches. This will allow both
log and RET_KILL logic to work off the filter rather than doing more
expensive tests inside the time-critical run_filters loop.
Running tight cycles of getpid() with filters attached shows no measurable
difference in speed.
Suggested-by: Tyler Hicks <tyhicks@canonical.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
(backported from commit deb4de8b31bc5bf21efb6ac31150a01a631cd647)
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 9e189a1bed487edd84687e73d564c4c4a6ba20a1
Author: Wen-chien Jesse Sung <jesse.sung@canonical.com>
Date: Fri Oct 6 09:19:06 2017 +0200
UBUNTU: SAUCE: update OpenNSL kernel modules to 6.5.10
BugLink: https://launchpad.net/bugs/1721511
The new version can be found at OpenNSL git repo:
https://github.com/Broadcom-Switch/OpenNSL/tree/v3.4.1.5
Signed-off-by: Wen-chien Jesse Sung <jesse.sung@canonical.com>
Acked-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 01683e9fc6cf52b1e2739b6fcabdec54aa7c784d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Thu Oct 5 09:41:59 2017 +0200
Linux 4.4.90
BugLink: http://bugs.launchpad.net/bugs/1721550
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit d5cd768afa0fead38412c45b55fce30f7620cf2b
Author: Arnd Bergmann <arnd@arndb.de>
Date: Wed Oct 4 15:51:29 2017 +0200
fix xen_swiotlb_dma_mmap prototype
BugLink: http://bugs.launchpad.net/bugs/1721550
xen_swiotlb_dma_mmap was backported from v4.10, but older
kernels before commit 00085f1efa38 ("dma-mapping: use unsigned long
for dma_attrs") use a different signature:
arm/xen/mm.c:202:10: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.mmap = xen_swiotlb_dma_mmap,
^~~~~~~~~~~~~~~~~~~~
arm/xen/mm.c:202:10: note: (near initialization for 'xen_swiotlb_dma_ops.mmap')
This adapts the patch to the old calling conventions.
Fixes: "swiotlb-xen: implement xen_swiotlb_dma_mmap callback"
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 37012690c95f902d06d41df589566362949f6585
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Tue Feb 7 19:58:02 2017 +0200
swiotlb-xen: implement xen_swiotlb_dma_mmap callback
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 7e91c7df29b5e196de3dc6f086c8937973bd0b88 upstream.
This function creates userspace mapping for the DMA-coherent memory.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 354452b1340fd93c9c61f89d9f02567c906c1c67
Author: Vladis Dronov <vdronov@redhat.com>
Date: Mon Sep 4 16:00:50 2017 +0200
video: fbdev: aty: do not leak uninitialized padding in clk to userspace
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 8e75f7a7a00461ef6d91797a60b606367f6e344d upstream.
'clk' is copied to a userland with padding byte(s) after 'vclk_post_div'
field unitialized, leaking data from the stack. Fix this ensuring all of
'clk' is initialized to zero.
References: https://github.com/torvalds/linux/pull/441
Reported-by: sohu0106 <sohu0106@126.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit f73d047ff53a3888c8f0f819e30fde14bdb3869c
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Thu Sep 28 17:58:41 2017 +0200
KVM: VMX: use cmpxchg64
BugLink: http://bugs.launchpad.net/bugs/1721550
commit c0a1666bcb2a33e84187a15eabdcd54056be9a97 upstream.
This fixes a compilation failure on 32-bit systems.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 8185a7db5ef3faad2f7673c475664bcec719d2ac
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Date: Wed Mar 9 00:46:11 2016 +0100
ARM: pxa: fix the number of DMA requestor lines
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 4c35430ad18f5a034302cb90e559ede5a27f93b9 upstream.
The number of requestor lines was clamped to 0 for all pxa architectures
in the requestor declaration. Fix this by using the value.
Fixes: 72b195cb7162 ("ARM: pxa: add the number of DMA requestor lines")
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit e2a32f50ee1e3559bfc9b9dec467f53de79f21ab
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Date: Mon Feb 15 21:57:47 2016 +0100
ARM: pxa: add the number of DMA requestor lines
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 72b195cb716284217e8b270af420bc7e5cf04b3c upstream.
Declare the number of DMA requestor lines per platform :
- for pxa25x: 40 requestor lines
- for pxa27x: 75 requestor lines
- for pxa3xx: 100 requestor lines
This information will be used to activate the DMA flow control or not.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 41a0602031127e53d2d33589a8f324fda85a2bd5
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Date: Mon Feb 15 21:57:46 2016 +0100
dmaengine: mmp-pdma: add number of requestors
BugLink: http://bugs.launchpad.net/bugs/1721550
commit c283e41ef32442f41e7180f9bb1c5aedf9255bfe upstream.
The DMA chip has a fixed number of requestor lines used for flow
control. This number is platform dependent. The pxa_dma dma driver will
use this value to activate or not the flow control.
There won't be any impact on mmp_pdma driver.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit d16597b8c4f0ca0c952b124f8f49b61152c98be0
Author: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Date: Wed Aug 30 12:15:49 2017 +0200
cxl: Fix driver use count
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 197267d0356004a31c4d6b6336598f5dff3301e1 upstream.
cxl keeps a driver use count, which is used with the hash memory model
on p8 to know when to upgrade local TLBIs to global and to trigger
callbacks to manage the MMU for PSL8.
If a process opens a context and closes without attaching or fails the
attachment, the driver use count is never decremented. As a
consequence, TLB invalidations remain global, even if there are no
active cxl contexts.
We should increment the driver use count when the process is attaching
to the cxl adapter, and not on open. It's not needed before the
adapter starts using the context and the use count is decremented on
the detach path, so it makes more sense.
It affects only the user api. The kernel api is already doing The
Right Thing.
Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Fixes: 7bb5d91a4dda ("cxl: Rework context lifetimes")
Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
[ajd: backport to stable v4.4 tree]
Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 5510c743e2ebfe4392e94bdee32b140ef82615df
Author: Haozhong Zhang <haozhong.zhang@intel.com>
Date: Mon Sep 18 09:56:50 2017 +0800
KVM: VMX: remove WARN_ON_ONCE in kvm_vcpu_trigger_posted_interrupt
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 5753743fa5108b8f98bd61e40dc63f641b26c768 upstream.
WARN_ON_ONCE(pi_test_sn(&vmx->pi_desc)) in kvm_vcpu_trigger_posted_interrupt()
intends to detect the violation of invariant that VT-d PI notification
event is not suppressed when vcpu is in the guest mode. Because the
two checks for the target vcpu mode and the target suppress field
cannot be performed atomically, the target vcpu mode may change in
between. If that does happen, WARN_ON_ONCE() here may raise false
alarms.
As the previous patch fixed the real invariant breaker, remove this
WARN_ON_ONCE() to avoid false alarms, and document the allowed cases
instead.
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
Reported-by: "Ramamurthy, Venkatesh" <venkatesh.ramamurthy@intel.com>
Reported-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Fixes: 28b835d60fcc ("KVM: Update Posted-Interrupts Descriptor when vCPU is preempted")
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 5c2898624597f0e0f925d0258529bb3602b759e4
Author: Haozhong Zhang <haozhong.zhang@intel.com>
Date: Mon Sep 18 09:56:49 2017 +0800
KVM: VMX: do not change SN bit in vmx_update_pi_irte()
BugLink: http://bugs.launchpad.net/bugs/1721550
commit dc91f2eb1a4021eb6705c15e474942f84ab9b211 upstream.
In kvm_vcpu_trigger_posted_interrupt() and pi_pre_block(), KVM
assumes that PI notification events should not be suppressed when the
target vCPU is not blocked.
vmx_update_pi_irte() sets the SN field before changing an interrupt
from posting to remapping, but it does not check the vCPU mode.
Therefore, the change of SN field may break above the assumption.
Besides, I don't see reasons to suppress notification events here, so
remove the changes of SN field to avoid race condition.
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
Reported-by: "Ramamurthy, Venkatesh" <venkatesh.ramamurthy@intel.com>
Reported-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Fixes: 28b835d60fcc ("KVM: Update Posted-Interrupts Descriptor when vCPU is preempted")
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 20f1b7919dda139de591f91f99bfcbd5a06b1e14
Author: Myungho Jung <mhjungk@gmail.com>
Date: Wed Apr 19 15:24:50 2017 -0700
timer/sysclt: Restrict timer migration sysctl values to 0 and 1
BugLink: http://bugs.launchpad.net/bugs/1721550
commit b94bf594cf8ed67cdd0439e70fa939783471597a upstream.
timer_migration sysctl acts as a boolean switch, so the allowed values
should be restricted to 0 and 1.
Add the necessary extra fields to the sysctl table entry to enforce that.
[ tglx: Rewrote changelog ]
Signed-off-by: Myungho Jung <mhjungk@gmail.com>
Link: http://lkml.kernel.org/r/1492640690-3550-1-git-send-email-mhjungk@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Kazuhiro Hayashi <kazuhiro3.hayashi@toshiba.co.jp>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 00503210f742ba762b8a629f62f24068d1227c14
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date: Tue Sep 19 07:15:35 2017 -0500
gfs2: Fix debugfs glocks dump
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 10201655b085df8e000822e496e5d4016a167a36 upstream.
The switch to rhashtables (commit 88ffbf3e03) broke the debugfs glock
dump (/sys/kernel/debug/gfs2/<device>/glocks) for dumps bigger than a
single buffer: the right function for restarting an rhashtable iteration
from the beginning of the hash table is rhashtable_walk_enter;
rhashtable_walk_stop + rhashtable_walk_start will just resume from the
current position.
The upstream commit doesn't directly apply to 4.4.y because 4.4.y
doesn't have rhashtable_walk_enter and the following mainline commits:
92ecd73a887c4a2b94daf5fc35179d75d1c4ef95
gfs2: Deduplicate gfs2_{glocks,glstats}_open
cc37a62785a584f4875788689f3fd1fa6e4eb291
gfs2: Replace rhashtable_walk_init with rhashtable_walk_enter
Other than rhashtable_walk_enter, rhashtable_walk_init can fail. To
handle the failure case in gfs2_glock_seq_stop, we check if
rhashtable_walk_init has initialized iter->walker; if it has not, we
must not call rhashtable_walk_stop or rhashtable_walk_exit.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 30985ef38f1370106852840b604e3e4143a2f4e7
Author: Eric Biggers <ebiggers@google.com>
Date: Mon Oct 2 11:04:09 2017 -0700
x86/fpu: Don't let userspace set bogus xcomp_bv
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 814fb7bb7db5433757d76f4c4502c96fc53b0b5e upstream.
[Please apply to 4.4-stable. Note: the backport includes the
fpstate_init() call in xstateregs_set(), since fix is useless without
it. It was added by commit 91c3dba7dbc1 ("x86/fpu/xstate: Fix PTRACE
frames for XSAVES"), but it doesn't make sense to backport that whole
commit.]
On x86, userspace can use the ptrace() or rt_sigreturn() system calls to
set a task's extended state (xstate) or "FPU" registers. ptrace() can
set them for another task using the PTRACE_SETREGSET request with
NT_X86_XSTATE, while rt_sigreturn() can set them for the current task.
In either case, registers can be set to any value, but the kernel
assumes that the XSAVE area itself remains valid in the sense that the
CPU can restore it.
However, in the case where the kernel is using the uncompacted xstate
format (which it does whenever the XSAVES instruction is unavailable),
it was possible for userspace to set the xcomp_bv field in the
xstate_header to an arbitrary value. However, all bits in that field
are reserved in the uncompacted case, so when switching to a task with
nonzero xcomp_bv, the XRSTOR instruction failed with a #GP fault. This
caused the WARN_ON_FPU(err) in copy_kernel_to_xregs() to be hit. In
addition, since the error is otherwise ignored, the FPU registers from
the task previously executing on the CPU were leaked.
Fix the bug by checking that the user-supplied value of xcomp_bv is 0 in
the uncompacted case, and returning an error otherwise.
The reason for validating xcomp_bv rather than simply overwriting it
with 0 is that we want userspace to see an error if it (incorrectly)
provides an XSAVE area in compacted format rather than in uncompacted
format.
Note that as before, in case of error we clear the task's FPU state.
This is perhaps non-ideal, especially for PTRACE_SETREGSET; it might be
better to return an error before changing anything. But it seems the
"clear on error" behavior is fine for now, and it's a little tricky to
do otherwise because it would mean we couldn't simply copy the full
userspace state into kernel memory in one __copy_from_user().
This bug was found by syzkaller, which hit the above-mentioned
WARN_ON_FPU():
WARNING: CPU: 1 PID: 0 at ./arch/x86/include/asm/fpu/internal.h:373 __switch_to+0x5b5/0x5d0
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.13.0 #453
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff9ba2bc8e42c0 task.stack: ffffa78cc036c000
RIP: 0010:__switch_to+0x5b5/0x5d0
RSP: 0000:ffffa78cc08bbb88 EFLAGS: 00010082
RAX: 00000000fffffffe RBX: ffff9ba2b8bf2180 RCX: 00000000c0000100
RDX: 00000000ffffffff RSI: 000000005cb10700 RDI: ffff9ba2b8bf36c0
RBP: ffffa78cc08bbbd0 R08: 00000000929fdf46 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000000 R12: ffff9ba2bc8e42c0
R13: 0000000000000000 R14: ffff9ba2b8bf3680 R15: ffff9ba2bf5d7b40
FS: 00007f7e5cb10700(0000) GS:ffff9ba2bf400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004005cc CR3: 0000000079fd5000 CR4: 00000000001406e0
Call Trace:
Code: 84 00 00 00 00 00 e9 11 fd ff ff 0f ff 66 0f 1f 84 00 00 00 00 00 e9 e7 fa ff ff 0f ff 66 0f 1f 84 00 00 00 00 00 e9 c2 fa ff ff <0f> ff 66 0f 1f 84 00 00 00 00 00 e9 d4 fc ff ff 66 66 2e 0f 1f
Here is a C reproducer. The expected behavior is that the program spin
forever with no output. However, on a buggy kernel running on a
processor with the "xsave" feature but without the "xsaves" feature
(e.g. Sandy Bridge through Broadwell for Intel), within a second or two
the program reports that the xmm registers were corrupted, i.e. were not
restored correctly. With CONFIG_X86_DEBUG_FPU=y it also hits the above
kernel warning.
#define _GNU_SOURCE
#include <stdbool.h>
#include <inttypes.h>
#include <linux/elf.h>
#include <stdio.h>
#include <sys/ptrace.h>
#include <sys/uio.h>
#include <sys/wait.h>
#include <unistd.h>
int main(void)
{
int pid = fork();
uint64_t xstate[512];
struct iovec iov = { .iov_base = xstate, .iov_len = sizeof(xstate) };
if (pid == 0) {
bool tracee = true;
for (int i = 0; i < sysconf(_SC_NPROCESSORS_ONLN) && tracee; i++)
tracee = (fork() != 0);
uint32_t xmm0[4] = { [0 ... 3] = tracee ? 0x00000000 : 0xDEADBEEF };
asm volatile(" movdqu %0, %%xmm0\n"
" mov %0, %%rbx\n"
"1: movdqu %%xmm0, %0\n"
" mov %0, %%rax\n"
" cmp %%rax, %%rbx\n"
" je 1b\n"
: "+m" (xmm0) : : "rax", "rbx", "xmm0");
printf("BUG: xmm registers corrupted! tracee=%d, xmm0=%08X%08X%08X%08X\n",
tracee, xmm0[0], xmm0[1], xmm0[2], xmm0[3]);
} else {
usleep(100000);
ptrace(PTRACE_ATTACH, pid, 0, 0);
wait(NULL);
ptrace(PTRACE_GETREGSET, pid, NT_X86_XSTATE, &iov);
xstate[65] = -1;
ptrace(PTRACE_SETREGSET, pid, NT_X86_XSTATE, &iov);
ptrace(PTRACE_CONT, pid, 0, 0);
wait(NULL);
}
return 1;
}
Note: the program only tests for the bug using the ptrace() system call.
The bug can also be reproduced using the rt_sigreturn() system call, but
only when called from a 32-bit program, since for 64-bit programs the
kernel restores the FPU state from the signal frame by doing XRSTOR
directly from userspace memory (with proper error checking).
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Rik van Riel <riel@redhat.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Eric Biggers <ebiggers3@gmail.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Kevin Hao <haokexin@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Halcrow <mhalcrow@google.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wanpeng Li <wanpeng.li@hotmail.com>
Cc: Yu-cheng Yu <yu-cheng.yu@intel.com>
Cc: kernel-hardening@lists.openwall.com
Fixes: 0b29643a5843 ("x86/xsaves: Change compacted format xsave area header")
Link: http://lkml.kernel.org/r/20170922174156.16780-2-ebiggers3@gmail.com
Link: http://lkml.kernel.org/r/20170923130016.21448-25-mingo@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit ad45ddb452b135811f22ade526efa04cf908f11f
Author: satoru takeuchi <satoru.takeuchi@gmail.com>
Date: Tue Sep 12 22:42:52 2017 +0900
btrfs: prevent to set invalid default subvolid
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 6d6d282932d1a609e60dc4467677e0e863682f57 upstream.
`btrfs sub set-default` succeeds to set an ID which isn't corresponding to any
fs/file tree. If such the bad ID is set to a filesystem, we can't mount this
filesystem without specifying `subvol` or `subvolid` mount options.
Fixes: 6ef5ed0d386b ("Btrfs: add ioctl and incompat flag to set the default mount subvol")
Signed-off-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
Reviewed-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 7d08e00266e9265591355d77535324a79a2de862
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date: Fri Sep 8 17:48:55 2017 +0900
btrfs: propagate error to btrfs_cmp_data_prepare caller
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 78ad4ce014d025f41b8dde3a81876832ead643cf upstream.
btrfs_cmp_data_prepare() (almost) always returns 0 i.e. ignoring errors
from gather_extent_pages(). While the pages are freed by
btrfs_cmp_data_free(), cmp->num_pages still has > 0. Then,
btrfs_extent_same() try to access the already freed pages causing faults
(or violates PageLocked assertion).
This patch just return the error as is so that the caller stop the process.
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Fixes: f441460202cb ("btrfs: fix deadlock with extent-same and readpage")
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit be5f93e0f67e3cbf3d08b96fbf6d2462076098a3
Author: Naohiro Aota <naohiro.aota@wdc.com>
Date: Fri Aug 25 14:15:14 2017 +0900
btrfs: fix NULL pointer dereference from free_reloc_roots()
BugLink: http://bugs.launchpad.net/bugs/1721550
commit bb166d7207432d3c7d10c45dc052f12ba3a2121d upstream.
__del_reloc_root should be called before freeing up reloc_root->node.
If not, calling __del_reloc_root() dereference reloc_root->node, causing
the system BUG.
Fixes: 6bdf131fac23 ("Btrfs: don't leak reloc root nodes on error")
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 01ef598752c2f711c5a13b7ce1d4782b41a654f3
Author: Nicolai Stange <nstange@suse.de>
Date: Mon Sep 11 09:45:40 2017 +0200
PCI: Fix race condition with driver_override
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 9561475db680f7144d2223a409dd3d7e322aca03 upstream.
The driver_override implementation is susceptible to a race condition when
different threads are reading vs. storing a different driver override. Add
locking to avoid the race condition.
This is in close analogy to commit 6265539776a0 ("driver core: platform:
fix race condition with driver_override") from Adrian Salido.
Fixes: 782a985d7af2 ("PCI: Introduce new device binding path using pci_dev.driver_override")
Signed-off-by: Nicolai Stange <nstange@suse.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 0be892c3db33c8d9d22e9ac7858a9db829b45b24
Author: Jim Mattson <jmattson@google.com>
Date: Tue Sep 12 13:02:54 2017 -0700
kvm: nVMX: Don't allow L2 to access the hardware CR8
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 51aa68e7d57e3217192d88ce90fd5b8ef29ec94f upstream.
If L1 does not specify the "use TPR shadow" VM-execution control in
vmcs12, then L0 must specify the "CR8-load exiting" and "CR8-store
exiting" VM-execution controls in vmcs02. Failure to do so will give
the L2 VM unrestricted read/write access to the hardware CR8.
This fixes CVE-2017-12154.
Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit d04ff9748aa68af51297911ca6c010be2966d98d
Author: Jan H. Schönherr <jschoenh@amazon.de>
Date: Thu Sep 7 19:02:30 2017 +0100
KVM: VMX: Do not BUG() on out-of-bounds guest IRQ
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 3a8b0677fc6180a467e26cc32ce6b0c09a32f9bb upstream.
The value of the guest_irq argument to vmx_update_pi_irte() is
ultimately coming from a KVM_IRQFD API call. Do not BUG() in
vmx_update_pi_irte() if the value is out-of bounds. (Especially,
since KVM as a whole seems to hang after that.)
Instead, print a message only once if we find that we don't have a
route for a certain IRQ (which can be out-of-bounds or within the
array).
This fixes CVE-2017-1000252.
Fixes: efc644048ecde54 ("KVM: x86: Update IRTE for posted-interrupts")
Signed-off-by: Jan H. Schönherr <jschoenh@amazon.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 97dd4725562107211fcc091dd97ae4e750a52e3a
Author: Will Deacon <will.deacon@arm.com>
Date: Fri Sep 29 12:27:41 2017 +0100
arm64: fault: Route pte translation faults via do_translation_fault
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 760bfb47c36a07741a089bf6a28e854ffbee7dc9 upstream.
We currently route pte translation faults via do_page_fault, which elides
the address check against TASK_SIZE before invoking the mm fault handling
code. However, this can cause issues with the path walking code in
conjunction with our word-at-a-time implementation because
load_unaligned_zeropad can end up faulting in kernel space if it reads
across a page boundary and runs into a page fault (e.g. by attempting to
read from a guard region).
In the case of such a fault, load_unaligned_zeropad has registered a
fixup to shift the valid data and pad with zeroes, however the abort is
reported as a level 3 translation fault and we dispatch it straight to
do_page_fault, despite it being a kernel address. This results in calling
a sleeping function from atomic context:
BUG: sleeping function called from invalid context at arch/arm64/mm/fault.c:313
in_atomic(): 0, irqs_disabled(): 0, pid: 10290
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[...]
[<ffffff8e016cd0cc>] ___might_sleep+0x134/0x144
[<ffffff8e016cd158>] __might_sleep+0x7c/0x8c
[<ffffff8e016977f0>] do_page_fault+0x140/0x330
[<ffffff8e01681328>] do_mem_abort+0x54/0xb0
Exception stack(0xfffffffb20247a70 to 0xfffffffb20247ba0)
[...]
[<ffffff8e016844fc>] el1_da+0x18/0x78
[<ffffff8e017f399c>] path_parentat+0x44/0x88
[<ffffff8e017f4c9c>] filename_parentat+0x5c/0xd8
[<ffffff8e017f5044>] filename_create+0x4c/0x128
[<ffffff8e017f59e4>] SyS_mkdirat+0x50/0xc8
[<ffffff8e01684e30>] el0_svc_naked+0x24/0x28
Code: 36380080 d5384100 f9400800 9402566d (d4210000)
---[ end trace 2d01889f2bca9b9f ]---
Fix this by dispatching all translation faults to do_translation_faults,
which avoids invoking the page fault logic for faults on kernel addresses.
Reported-by: Ankit Jain <ankijain@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 26149820c808e2846972846496cf6a267d4006cb
Author: Marc Zyngier <marc.zyngier@arm.com>
Date: Tue Sep 26 15:57:16 2017 +0100
arm64: Make sure SPsel is always set
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 5371513fb338fb9989c569dc071326d369d6ade8 upstream.
When the kernel is entered at EL2 on an ARMv8.0 system, we construct
the EL1 pstate and make sure this uses the the EL1 stack pointer
(we perform an exception return to EL1h).
But if the kernel is either entered at EL1 or stays at EL2 (because
we're on a VHE-capable system), we fail to set SPsel, and use whatever
stack selection the higher exception level has choosen for us.
Let's not take any chance, and make sure that SPsel is set to one
before we decide the mode we're going to run in.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 236de4e67c64a3850f6f1c8ee81bf5961f1ebc80
Author: Oleg Nesterov <oleg@redhat.com>
Date: Wed Sep 27 09:25:30 2017 -0600
seccomp: fix the usage of get/put_seccomp_filter() in seccomp_get_filter()
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 66a733ea6b611aecf0119514d2dddab5f9d6c01e upstream.
As Chris explains, get_seccomp_filter() and put_seccomp_filter() can end
up using different filters. Once we drop ->siglock it is possible for
task->seccomp.filter to have been replaced by SECCOMP_FILTER_FLAG_TSYNC.
Fixes: f8e529ed941b ("seccomp, ptrace: add support for dumping seccomp filters")
Reported-by: Chris Salls <chrissalls5@gmail.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
[tycho: add __get_seccomp_filter vs. open coding refcount_inc()]
Signed-off-by: Tycho Andersen <tycho@docker.com>
[kees: tweak commit log]
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit ae80264367d76604c4af92a6700ede72a585bb0d
Author: Christoph Hellwig <hch@lst.de>
Date: Thu Sep 7 13:54:35 2017 +0200
bsg-lib: don't free job in bsg_prepare_job
BugLink: http://bugs.launchpad.net/bugs/1721550
commit f507b54dccfd8000c517d740bc45f20c74532d18 upstream.
The job structure is allocated as part of the request, so we should not
free it in the error path of bsg_prepare_job.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 1e82abc154c00e7cc56ef67250c6430b397b0930
Author: Vladis Dronov <vdronov@redhat.com>
Date: Wed Sep 13 00:21:21 2017 +0200
nl80211: check for the required netlink attributes presence
BugLink: http://bugs.launchpad.net/bugs/1721550
commit e785fa0a164aa11001cba931367c7f94ffaff888 upstream.
nl80211_set_rekey_data() does not check if the required attributes
NL80211_REKEY_DATA_{REPLAY_CTR,KEK,KCK} are present when processing
NL80211_CMD_SET_REKEY_OFFLOAD request. This request can be issued by
users with CAP_NET_ADMIN privilege and may result in NULL dereference
and a system crash. Add a check for the required attributes presence.
This patch is based on the patch by bo Zhang.
This fixes CVE-2017-12153.
References: https://bugzilla.redhat.com/show_bug.cgi?id=1491046
Fixes: e5497d766ad ("cfg80211/nl80211: support GTK rekey offload")
Reported-by: bo Zhang <zhangbo5891001@gmail.com>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 10e98800df1d94ec3b5d91dac7123c2e20c7fe26
Author: Andreas Gruenbacher <agruenba@redhat.com>
Date: Mon Sep 25 12:23:03 2017 +0200
vfs: Return -ENXIO for negative SEEK_HOLE / SEEK_DATA offsets
BugLink: http://bugs.launchpad.net/bugs/1721550
commit fc46820b27a2d9a46f7e90c9ceb4a64a1bc5fab8 upstream.
In generic_file_llseek_size, return -ENXIO for negative offsets as well
as offsets beyond EOF. This affects filesystems which don't implement
SEEK_HOLE / SEEK_DATA internally, possibly because they don't support
holes.
Fixes xfstest generic/448.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 38e4532c2c7ee00bf66647dd4c88ad7131b70752
Author: Steve French <smfrench@gmail.com>
Date: Fri Sep 22 01:40:27 2017 -0500
SMB3: Don't ignore O_SYNC/O_DSYNC and O_DIRECT flags
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 1013e760d10e614dc10b5624ce9fc41563ba2e65 upstream.
Signed-off-by: Steve French <smfrench@gmail.com>
Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit 29375fe72a51678a043c76b8dd7fbe537719bc4d
Author: Steve French <smfrench@gmail.com>
Date: Wed Sep 20 19:57:18 2017 -0500
SMB: Validate negotiate (to protect against downgrade) even if signing off
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 0603c96f3af50e2f9299fa410c224ab1d465e0f9 upstream.
As long as signing is supported (ie not a guest user connection) and
connection is SMB3 or SMB3.02, then validate negotiate (protect
against man in the middle downgrade attacks). We had been doing this
only when signing was required, not when signing was just enabled,
but this more closely matches recommended SMB3 behavior and is
better security. Suggested by Metze.
Signed-off-by: Steve French <smfrench@gmail.com>
Reviewed-by: Jeremy Allison <jra@samba.org>
Acked-by: Stefan Metzmacher <metze@samba.org>
Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit a26167cd2c854e3f20f57d8996c1212b28f5e56d
Author: Steve French <smfrench@gmail.com>
Date: Mon Sep 18 18:18:45 2017 -0500
Fix SMB3.1.1 guest authentication to Samba
BugLink: http://bugs.launchpad.net/bugs/1721550
commit 23586b66d84ba3184b8820277f3fc42761640f87 upstream.
Samba rejects SMB3.1.1 dialect (vers=3.1.1) negotiate requests from
the kernel client due to the two byte pad at the end of the negotiate
contexts.
Signed-off-by: Steve French <smfrench@gmail.com>
Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
commit c6540f6c259b3d0b2e7c5ee3de79e7ed6050bce8
Author: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Date: Wed Sep 20 17:02:52 2017 -0400
powerpc/pseries: Fix parent_dn reference leak in add_dt_node()
BugLink: http://bugs.launchpad.net/bugs/1721550
commit b537ca6fede69a281dc524983e5e633d79a10a08 upstream.
A reference to the parent device node is held by add_dt_node() for the
node to be added. If the call to dlpar_configure_connector() fails
add_dt_node() returns ENOENT and that reference is not freed.
Add a call…- Loading branch information
