In file included from scripts/selinux/genheaders/genheaders.c:18:
./security/selinux/include/classmap.h:238:2: error: #error New
address family defined, please update secclass_map. #error New
address family defined, please update secclass_map. ^~~~~
make[3]: *** [scripts/Makefile.host:107:
scripts/selinux/genheaders/genheaders] Error 1 make[2]: ***
[scripts/Makefile.build:599: scripts/selinux/genheaders] Error 2
make[1]: *** [scripts/Makefile.build:599: scripts/selinux] Error 2
make[1]: *** Waiting for unfinished jobs....
Instead of relying on the host definition, include linux/socket.h in
classmap.h to have PF_MAX.
Cc: stable@vger.kernel.org Signed-off-by: Paulo Alcantara <paulo@paulo.ac> Acked-by: Stephen Smalley <sds@tycho.nsa.gov>
[PM: manually merge in mdp.c, subject line tweaks] Signed-off-by: Paul Moore <paul@paul-moore.com>
(cherry picked from commit dfbd199a7cfe3e3cd8531e1353cdbd7175bfbc5e) Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
[ kleber: fix BugLink reference. ] Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Nadav Amit [Fri, 14 Jun 2019 08:55:06 +0000 (10:55 +0200)]
x86/mm: Use WRITE_ONCE() when setting PTEs
BugLink: https://bugs.launchpad.net/bugs/1830433
When page-table entries are set, the compiler might optimize their
assignment by using multiple instructions to set the PTE. This might
turn into a security hazard if the user somehow manages to use the
interim PTE. L1TF does not make our lives easier, making even an interim
non-present PTE a security hazard.
Using WRITE_ONCE() to set PTEs and friends should prevent this potential
security hazard.
I skimmed the differences in the binary with and without this patch. The
differences are (obviously) greater when CONFIG_PARAVIRT=n as more
code optimizations are possible. For better and worse, the impact on the
binary with this patch is pretty small. Skimming the code did not cause
anything to jump out as a security hazard, but it seems that at least
move_soft_dirty_pte() caused set_pte_at() to use multiple writes.
Signed-off-by: Nadav Amit <namit@vmware.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Sean Christopherson <sean.j.christopherson@intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180902181451.80520-1-namit@vmware.com
(backported from commit 9bc4f28af75a91aea0ae383f50b0a430c4509303) Tested-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1830433
We need an atomic way to setup pmd page table entry, avoiding races with
CPU setting dirty/accessed bits. This is required to implement
pmdp_invalidate() that doesn't lose these bits.
On PAE we can avoid expensive cmpxchg8b for cases when new page table
entry is not present. If it's present, fallback to cpmxchg loop.
[akpm@linux-foundation.org: add missing `do' to do-while loop] Link: http://lkml.kernel.org/r/20171213105756.69879-10-kirill.shutemov@linux.intel.com Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Michal Hocko <mhocko@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 86fa949b050184ffc53688516a6a83ae5f98d08a) Tested-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
Vlastimil Babka [Fri, 14 Jun 2019 08:55:04 +0000 (10:55 +0200)]
x86/init: fix build with CONFIG_SWAP=n
BugLink: https://bugs.launchpad.net/bugs/1830433
The introduction of generic_max_swapfile_size and arch-specific versions has
broken linking on x86 with CONFIG_SWAP=n due to undefined reference to
'generic_max_swapfile_size'. Fix it by compiling the x86-specific
max_swapfile_size() only with CONFIG_SWAP=y.
Reported-by: Tomas Pruzina <pruzinat@gmail.com> Fixes: 377eeaa8e11f ("x86/speculation/l1tf: Limit swap file size to MAX_PA/2") Signed-off-by: Vlastimil Babka <vbabka@suse.cz> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 792adb90fa724ce07c0171cbc96b9215af4b1045) Tested-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
Toshi Kani [Fri, 14 Jun 2019 08:55:03 +0000 (10:55 +0200)]
x86/mm: Add TLB purge to free pmd/pte page interfaces
BugLink: https://bugs.launchpad.net/bugs/1830433
ioremap() calls pud_free_pmd_page() / pmd_free_pte_page() when it creates
a pud / pmd map. The following preconditions are met at their entry.
- All pte entries for a target pud/pmd address range have been cleared.
- System-wide TLB purges have been peformed for a target pud/pmd address
range.
The preconditions assure that there is no stale TLB entry for the range.
Speculation may not cache TLB entries since it requires all levels of page
entries, including ptes, to have P & A-bits set for an associated address.
However, speculation may cache pud/pmd entries (paging-structure caches)
when they have P-bit set.
Add a system-wide TLB purge (INVLPG) to a single page after clearing
pud/pmd entry's P-bit.
SDM 4.10.4.1, Operation that Invalidate TLBs and Paging-Structure Caches,
states that:
INVLPG invalidates all paging-structure caches associated with the
current PCID regardless of the liner addresses to which they correspond.
Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces") Signed-off-by: Toshi Kani <toshi.kani@hpe.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: mhocko@suse.com Cc: akpm@linux-foundation.org Cc: hpa@zytor.com Cc: cpandya@codeaurora.org Cc: linux-mm@kvack.org Cc: linux-arm-kernel@lists.infradead.org Cc: Joerg Roedel <joro@8bytes.org> Cc: stable@vger.kernel.org Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Hocko <mhocko@suse.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20180627141348.21777-4-toshi.kani@hpe.com
(cherry picked from commit 5e0fb5df2ee871b841f96f9cb6a7f2784e96aa4e) Tested-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
1. ioremap with 4K size, a valid pte page table is set.
2. iounmap it, its pte entry is set to 0.
3. ioremap the same address with 2M size, update its pmd entry with
a new value.
4. CPU may hit an exception because the old pmd entry is still in TLB,
which leads to a kernel panic.
Commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page
table") has addressed this panic by falling to pte mappings in the above
case on ARM64.
To support pmd mappings in all cases, TLB purge needs to be performed
in this case on ARM64.
Add a new arg, 'addr', to pud_free_pmd_page() and pmd_free_pte_page()
so that TLB purge can be added later in seprate patches.
[toshi.kani@hpe.com: merge changes, rewrite patch description] Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces") Signed-off-by: Chintan Pandya <cpandya@codeaurora.org> Signed-off-by: Toshi Kani <toshi.kani@hpe.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: mhocko@suse.com Cc: akpm@linux-foundation.org Cc: hpa@zytor.com Cc: linux-mm@kvack.org Cc: linux-arm-kernel@lists.infradead.org Cc: Will Deacon <will.deacon@arm.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: stable@vger.kernel.org Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Hocko <mhocko@suse.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20180627141348.21777-3-toshi.kani@hpe.com
(cherry picked from commit 785a19f9d1dd8a4ab2d0633be4656653bd3de1fc) Tested-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
Toshi Kani [Fri, 14 Jun 2019 08:55:01 +0000 (10:55 +0200)]
x86/mm: Disable ioremap free page handling on x86-PAE
BugLink: https://bugs.launchpad.net/bugs/1830433
ioremap() supports pmd mappings on x86-PAE. However, kernel's pmd
tables are not shared among processes on x86-PAE. Therefore, any
update to sync'd pmd entries need re-syncing. Freeing a pte page
also leads to a vmalloc fault and hits the BUG_ON in vmalloc_sync_one().
Disable free page handling on x86-PAE. pud_free_pmd_page() and
pmd_free_pte_page() simply return 0 if a given pud/pmd entry is present.
This assures that ioremap() does not update sync'd pmd entries at the
cost of falling back to pte mappings.
Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces") Reported-by: Joerg Roedel <joro@8bytes.org> Signed-off-by: Toshi Kani <toshi.kani@hpe.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: mhocko@suse.com Cc: akpm@linux-foundation.org Cc: hpa@zytor.com Cc: cpandya@codeaurora.org Cc: linux-mm@kvack.org Cc: linux-arm-kernel@lists.infradead.org Cc: stable@vger.kernel.org Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Michal Hocko <mhocko@suse.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20180627141348.21777-2-toshi.kani@hpe.com
(cherry picked from commit f967db0b9ed44ec3057a28f3b28efc51df51b835) Tested-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
f77084d96355 "x86/mm/pat: Disable preemption around __flush_tlb_all()"
addressed a case where __flush_tlb_all() is called without preemption
being disabled. It also left a warning to catch other cases where
preemption is not disabled.
That warning triggers for the memory hotplug path which is also used for
persistent memory enabling:
Andy wondered why a path that can sleep was using __flush_tlb_all() [1]
and Dave confirmed the expectation for TLB flush is for modifying /
invalidating existing PTE entries, but not initial population [2]. Drop
the usage of __flush_tlb_all() in phys_{p4d,pud,pmd}_init() on the
expectation that this path is only ever populating empty entries for the
linear map. Note, at linear map teardown time there is a call to the
all-cpu flush_tlb_all() to invalidate the removed mappings.
x86/mm/pat: Disable preemption around __flush_tlb_all()
BugLink: https://bugs.launchpad.net/bugs/1830433
The WARN_ON_ONCE(__read_cr3() != build_cr3()) in switch_mm_irqs_off()
triggers every once in a while during a snapshotted system upgrade.
The warning triggers since commit decab0888e6e ("x86/mm: Remove
preempt_disable/enable() from __native_flush_tlb()"). The callchain is:
Disable preemption during CR3 reset / __flush_tlb_all() and add a comment
why preemption has to be disabled so it won't be removed accidentaly.
Add another preemptible() check in __flush_tlb_all() to catch callers with
enabled preemption when PGE is enabled, because PGE enabled does not
trigger the warning in __native_flush_tlb(). Suggested by Andy Lutomirski.
Fixes: decab0888e6e ("x86/mm: Remove preempt_disable/enable() from __native_flush_tlb()") Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Borislav Petkov <bp@alien8.de> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20181017103432.zgv46nlu3hc7k4rq@linutronix.de
(cherry picked from commit f77084d96355f5fba8e2c1fb3a51a393b1570de7) Tested-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
Xue Chaojing [Tue, 18 Jun 2019 00:26:07 +0000 (18:26 -0600)]
hinic: fix a bug in set rx mode
BugLink: https://bugs.launchpad.net/bugs/1832048
in set_rx_mode, __dev_mc_sync and netdev_for_each_mc_addr will
repeatedly set the multicast mac address. so we delete this loop.
Signed-off-by: Xue Chaojing <xuechaojing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 66350023d57560b2ead168af098fc507e58d8e6a linux-next) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
Christian König [Tue, 18 Jun 2019 03:10:21 +0000 (11:10 +0800)]
drm/radeon: prefer lower reference dividers
BugLink: https://bugs.launchpad.net/bugs/1791312
Instead of the closest reference divider prefer the lowest,
this fixes flickering issues on HP Compaq nx9420.
Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=108514 Suggested-by: Paul Dufresne <dufresnep@gmail.com> Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
(cherry picked from commit 2e26ccb119bde03584be53406bbd22e711b0d6e6) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
Arnd Bergmann [Fri, 21 Jun 2019 00:26:41 +0000 (20:26 -0400)]
drm/vmwgfx: use monotonic event timestamps
BugLink: https://launchpad.net/bugs/1832138
DRM_VMW_EVENT_FENCE_SIGNALED (struct drm_vmw_event_fence) and
DRM_EVENT_VBLANK (struct drm_event_vblank) pass timestamps in 32-bit
seconds/microseconds format.
As of commit c61eef726a78 ("drm: add support for monotonic vblank
timestamps"), other DRM drivers use monotonic times for drm_event_vblank,
but vmwgfx still uses CLOCK_REALTIME for both events, which suffers from
the y2038/y2106 overflow as well as time jumps.
For consistency, this changes vmwgfx to use ktime_get_ts64 as well,
which solves those problems and avoids the deprecated do_gettimeofday()
function.
This should be transparent to to user space, as long as it doesn't
compare the time against the result of gettimeofday().
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
(cherry picked from commit 37efe80ce85f76b3b30d7b4ea40550e6a5a5b71a) Signed-off-by: Eric Desrochers <eric.desrochers@canonical.com> Signed-off-by: Daniel van Vugt <daniel.van.vugt@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
Keith Busch [Thu, 27 Jun 2019 18:16:00 +0000 (20:16 +0200)]
block: Clear kernel memory before copying to user
BugLink: http://bugs.launchpad.net/bugs/1834499
If the kernel allocates a bounce buffer for user read data, this memory
needs to be cleared before copying it to the user, otherwise it may leak
kernel memory to user space.
Laurence Oberman <loberman@redhat.com> Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
(cherry picked from commit f3587d76da05f68098ddb1cb3c98cc6a9e8a402c) Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Dan Streetman [Sun, 2 Jun 2019 14:10:00 +0000 (16:10 +0200)]
UBUNTU: [Config] CONFIG_LOG_BUF_SHIFT=18 on all 64bit arches
BugLink: https://bugs.launchpad.net/bugs/1824864
All other archs have this value set higher, and the low value of 14
results in a log buffer so small it fills up before systemd-journald
can start and read all the boot time kernel log messages.
Increasing this will result in more memory reserved for the log buffer,
but will avoid missed kernel log messages.
This changes all 64 bit archs to use a shift of 18, which is what
amd64 has been using.
Signed-off-by: Dan Streetman <ddstreet@canonical.com> Cc: Dimitri John Ledkov <xnox@ubuntu.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com>
[ kleber: fixed subject line. ] Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Will Deacon [Fri, 28 Jun 2019 08:24:00 +0000 (10:24 +0200)]
kernel/sysctl.c: fix out-of-bounds access when setting file-max
BugLink: https://bugs.launchpad.net/bugs/1834310
Commit 32a5ad9c2285 ("sysctl: handle overflow for file-max") hooked up
min/max values for the file-max sysctl parameter via the .extra1 and
.extra2 fields in the corresponding struct ctl_table entry.
Unfortunately, the minimum value points at the global 'zero' variable,
which is an int. This results in a KASAN splat when accessed as a long
by proc_doulongvec_minmax on 64-bit architectures:
| BUG: KASAN: global-out-of-bounds in __do_proc_doulongvec_minmax+0x5d8/0x6a0
| Read of size 8 at addr ffff2000133d1c20 by task systemd/1
|
| CPU: 0 PID: 1 Comm: systemd Not tainted 5.1.0-rc3-00012-g40b114779944 #2
| Hardware name: linux,dummy-virt (DT)
| Call trace:
| dump_backtrace+0x0/0x228
| show_stack+0x14/0x20
| dump_stack+0xe8/0x124
| print_address_description+0x60/0x258
| kasan_report+0x140/0x1a0
| __asan_report_load8_noabort+0x18/0x20
| __do_proc_doulongvec_minmax+0x5d8/0x6a0
| proc_doulongvec_minmax+0x4c/0x78
| proc_sys_call_handler.isra.19+0x144/0x1d8
| proc_sys_write+0x34/0x58
| __vfs_write+0x54/0xe8
| vfs_write+0x124/0x3c0
| ksys_write+0xbc/0x168
| __arm64_sys_write+0x68/0x98
| el0_svc_common+0x100/0x258
| el0_svc_handler+0x48/0xc0
| el0_svc+0x8/0xc
|
| The buggy address belongs to the variable:
| zero+0x0/0x40
|
| Memory state around the buggy address:
| ffff2000133d1b00: 00 00 00 00 00 00 00 00 fa fa fa fa 04 fa fa fa
| ffff2000133d1b80: fa fa fa fa 04 fa fa fa fa fa fa fa 04 fa fa fa
| >ffff2000133d1c00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00
| ^
| ffff2000133d1c80: fa fa fa fa 00 fa fa fa fa fa fa fa 00 00 00 00
| ffff2000133d1d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Fix the splat by introducing a unsigned long 'zero_ul' and using that
instead.
Link: http://lkml.kernel.org/r/20190403153409.17307-1-will.deacon@arm.com Fixes: 32a5ad9c2285 ("sysctl: handle overflow for file-max") Signed-off-by: Will Deacon <will.deacon@arm.com> Acked-by: Christian Brauner <christian@brauner.io> Cc: Kees Cook <keescook@chromium.org> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Matteo Croce <mcroce@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 9002b21465fa4d829edfc94a5a441005cffaa972) Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
/proc/sys/fs/file-max will overflow and be set to 0. That quickly
crashes the system.
This commit sets the max and min value for file-max. The max value is
set to long int. Any higher value cannot currently be used as the
percpu counters are long ints and not unsigned integers.
Note that the file-max value is ultimately parsed via
__do_proc_doulongvec_minmax(). This function does not report error when
min or max are exceeded. Which means if a value largen that long int is
written userspace will not receive an error instead the old value will be
kept. There is an argument to be made that this should be changed and
__do_proc_doulongvec_minmax() should return an error when a dedicated min
or max value are exceeded. However this has the potential to break
userspace so let's defer this to an RFC patch.
Link: http://lkml.kernel.org/r/20190107222700.15954-3-christian@brauner.io Signed-off-by: Christian Brauner <christian@brauner.io> Acked-by: Kees Cook <keescook@chromium.org> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Joe Lawrence <joe.lawrence@redhat.com> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: Waiman Long <longman@redhat.com>
[christian@brauner.io: v4] Link: http://lkml.kernel.org/r/20190210203943.8227-3-christian@brauner.io Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 32a5ad9c22852e6bd9e74bdec5934ef9d1480bc5) Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Jeremy Soller [Wed, 5 Jun 2019 17:54:00 +0000 (19:54 +0200)]
ALSA: hda/realtek - Corrected fixup for System76 Gazelle (gaze14)
BugLink: https://bugs.launchpad.net/bugs/1827555
A mistake was made in the identification of the four variants of the
System76 Gazelle (gaze14). This patch corrects the PCI ID of the
17-inch, GTX 1660 Ti variant from 0x8560 to 0x8551. This patch also
adds the correct fixups for the 15-inch and 17-inch GTX 1650 variants
with PCI IDs 0x8560 and 0x8561.
Tests were done on all four variants ensuring full audio capability.
Fixes: 80a5052db751 ("ALSA: hdea/realtek - Headset fixup for System76 Gazelle (gaze14)") Signed-off-by: Jeremy Soller <jeremy@system76.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 891afcf2462d2cc4ef7caf94215358ca61fa32cb) Signed-off-by: Jeremy Soller <jeremy@system76.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Jeremy Soller [Wed, 5 Jun 2019 17:54:00 +0000 (19:54 +0200)]
ALSA: hda/realtek - Headset fixup for System76 Gazelle (gaze14)
BugLink: https://bugs.launchpad.net/bugs/1827555
On the System76 Gazelle (gaze14), there is a headset microphone input
attached to 0x1a that does not have a jack detect. In order to get it
working, the pin configuration needs to be set correctly, and the
ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC fixup needs to be applied. This is
identical to the patch already applied for the System76 Darter Pro
(darp5).
Signed-off-by: Jeremy Soller <jeremy@system76.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 80a5052db75131423b67f38b21958555d7d970e4) Signed-off-by: Jeremy Soller <jeremy@system76.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Will Deacon [Mon, 3 Jun 2019 21:16:00 +0000 (23:16 +0200)]
iommu/arm-smmu-v3: Don't disable SMMU in kdump kernel
BugLink: https://bugs.launchpad.net/bugs/1828868
Disabling the SMMU when probing from within a kdump kernel so that all
incoming transactions are terminated can prevent the core of the crashed
kernel from being transferred off the machine if all I/O devices are
behind the SMMU.
Instead, continue to probe the SMMU after it is disabled so that we can
reinitialise it entirely and re-attach the DMA masters as they are reset.
Since the kdump kernel may not have drivers for all of the active DMA
masters, we suppress fault reporting to avoid spamming the console and
swamping the IRQ threads.
Reported-by: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com> Tested-by: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com> Tested-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
(cherry picked from commit 3f54c447df34ff9efac7809a4a80fd3208efc619) Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Will Deacon [Mon, 3 Jun 2019 21:16:00 +0000 (23:16 +0200)]
iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel
BugLink: https://bugs.launchpad.net/bugs/1828868
If we find that the SMMU is enabled during probe, we reset it by
re-initialising its registers and either enabling translation or placing
it into bypass based on the disable_bypass commandline option.
In the case of a kdump kernel, the SMMU won't have been shutdown cleanly
by the previous kernel and there may be concurrent DMA through the SMMU.
Rather than reset the SMMU to bypass, which would likely lead to rampant
data corruption, we can instead configure the SMMU to abort all incoming
transactions when we find that it is enabled from within a kdump kernel.
Reported-by: Sameer Goel <sgoel@codeaurora.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
(backported from commit b63b3439b85609338e4faabd5d2588dbda137e5c)
[ dannf: trivial offset adjustment in #include section ] Signed-off-by: dann frazier <dann.frazier@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
ext4: zero out the unused memory region in the extent tree block
CVE-2019-11833
This commit zeroes out the unused memory region in the buffer_head
corresponding to the extent metablock after writing the extent header
and the corresponding extent node entries.
This is done to prevent random uninitialized data from getting into
the filesystem when the extent block is synced.
This fixes CVE-2019-11833.
Signed-off-by: Sriram Rajagopalan <sriramr@arista.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org
(cherry picked from commit 592acbf16821288ecdc4192c47e3774a4c48bb64) Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Adds a dedicated, per-pool, prefetch taskq to prevent the traverse
code from monopolizing the global (and limited) system_taskq by
inappropriately scheduling long running tasks on it. This fixes
z_zvol hung tasks when performing large I/O operations, for example
when performing huge ZFS send/receives (on slow media).
Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Takashi Iwai [Thu, 30 May 2019 12:00:00 +0000 (14:00 +0200)]
ALSA: hda/realtek - Use a common helper for hp pin reference
BugLink: https://launchpad.net/bugs/1831065
Replace the open-codes in many places with a new common helper for
performing the same thing: referring to the primary headphone pin.
This eventually fixes the potentially missing headphone pin on some
weird devices, too.
Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 35a39f98567d8d3f1cea48f0f30de1a7e736b644) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Anthony Wong <anthony.wong@canonical.com> Acked-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
The hp_pin value that is referred in alc294_hp_init() is always zero
at the moment the function gets called, hence this is actually
useless as in the current code.
And, this kind of init sequence should be called from the codec init
callback, instead of the parser function. So, the first fix in this
patch to move the call call into its own init_hook.
OTOH, this function is needed to be called only once after the boot,
and it'd take too long for invoking at each resume (where the init
callback gets called). So we add a new flag and invoke this only
once as an additional fix.
The one case is still not covered, though: S4 resume. But this
change itself won't lead to any regression in that regard, so we
leave S4 issue as is for now and fix it later. -- tiwai ]
Fixes: bde1a7459623 ("ALSA: hda/realtek - Fixed headphone issue for ALC700") Signed-off-by: Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 693abe11aa6b27aed6eb8222162f8fb986325cef) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Anthony Wong <anthony.wong@canonical.com> Acked-by: AceLan Kao <acelan.kao@canonical.com>
[ kleber: context adjustments ] Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
For the local variable 'cr', its exts part is never used but
initialized without being released properly on success path. So
just completely remove the exts part to fix this leak.
For the local variable 'new_filter_result', it is never properly
released if not used by 'r' on success path.
Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 1db817e75f5b9387b8db11e37d5f0624eb9223e0) Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Cong Wang [Wed, 15 May 2019 13:02:00 +0000 (15:02 +0200)]
net_sched: initialize net pointer inside tcf_exts_init()
BugLink: https://bugs.launchpad.net/bugs/1825942
For tcindex filter, it is too late to initialize the
net pointer in tcf_exts_validate(), as tcf_exts_get_net()
requires a non-NULL net pointer. We can just move its
initialization into tcf_exts_init(), which just requires
an additional parameter.
This makes the code in tcindex_alloc_perfect_hash()
prettier.
Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 14215108a1fd7e002c0a1f9faf8fbaf41fdda50d) Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Cong Wang [Wed, 15 May 2019 13:02:00 +0000 (15:02 +0200)]
net_sched: fix a memory leak in cls_tcindex
BugLink: https://bugs.launchpad.net/bugs/1825942
When tcindex_destroy() destroys all the filter results in
the perfect hash table, it invokes the walker to delete
each of them. However, results with class==0 are skipped
in either tcindex_walk() or tcindex_delete(), which causes
a memory leak reported by kmemleak.
This patch fixes it by skipping the walker and directly
deleting these filter results so we don't miss any filter
result.
As a result of this change, we have to initialize exts->net
properly in tcindex_alloc_perfect_hash(). For net-next, we
need to consider whether we should initialize ->net in
tcf_exts_init() instead, before that just directly test
CONFIG_NET_CLS_ACT=y.
Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(backported from commit 033b228e7f26b29ae37f8bfa1bc6b209a5365e9f) Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Cong Wang [Wed, 15 May 2019 13:02:00 +0000 (15:02 +0200)]
net_sched: fix a race condition in tcindex_destroy()
BugLink: https://bugs.launchpad.net/bugs/1825942
tcindex_destroy() invokes tcindex_destroy_element() via
a walker to delete each filter result in its perfect hash
table, and tcindex_destroy_element() calls tcindex_delete()
which schedules tcf RCU works to do the final deletion work.
Unfortunately this races with the RCU callback
__tcindex_destroy(), which could lead to use-after-free as
reported by Adrian.
Fix this by migrating this RCU callback to tcf RCU work too,
as that workqueue is ordered, we will not have use-after-free.
Note, we don't need to hold netns refcnt because we don't call
tcf_exts_destroy() here.
Fixes: 27ce4f05e2ab ("net_sched: use tcf_queue_work() in tcindex filter") Reported-by: Adrian <bugs@abtelecom.ro> Cc: Ben Hutchings <ben@decadent.org.uk> Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 8015d93ebd27484418d4952284fd02172fa4b0b2) Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Cong Wang [Wed, 15 May 2019 13:02:00 +0000 (15:02 +0200)]
net_sched: switch to rcu_work
BugLink: https://bugs.launchpad.net/bugs/1825942
Commit 05f0fe6b74db ("RCU, workqueue: Implement rcu_work") introduces
new API's for dispatching work in a RCU callback. Now we can just
switch to the new API's for tc filters. This could get rid of a lot
of code.
Cc: Tejun Heo <tj@kernel.org> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(backported from commit aaa908ffbee18a65529b716efb346a626e81559a) Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Tejun Heo [Wed, 15 May 2019 13:02:00 +0000 (15:02 +0200)]
RCU, workqueue: Implement rcu_work
BugLink: https://bugs.launchpad.net/bugs/1825942
There are cases where RCU callback needs to be bounced to a sleepable
context. This is currently done by the RCU callback queueing a work
item, which can be cumbersome to write and confusing to read.
This patch introduces rcu_work, a workqueue work variant which gets
executed after a RCU grace period, and converts the open coded
bouncing in fs/aio and kernel/cgroup.
v3: Dropped queue_rcu_work_on(). Documented rcu grace period behavior
after queue_rcu_work().
v2: Use rcu_barrier() instead of synchronize_rcu() to wait for
completion of previously queued rcu callback as per Paul.
Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 05f0fe6b74dbd7690a4cbd61810948b7d575576a) Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Reproducer:
tc qdisc add dev lo handle 1:0 root dsmark indices 64 set_tc_index
tc filter add dev lo parent 1:0 protocol ip prio 1 tcindex mask 0xfc shift 2
tc qdisc add dev lo parent 1:0 handle 2:0 cbq bandwidth 10Mbit cell 8 avpkt 1000 mpu 64
tc class add dev lo parent 2:0 classid 2:1 cbq bandwidth 10Mbit rate 1500Kbit avpkt 1000 prio 1 bounded isolated allot 1514 weight 1 maxburst 10
tc filter add dev lo parent 2:0 protocol ip prio 1 handle 0x2e tcindex classid 2:1 pass_on
tc qdisc add dev lo parent 2:1 pfifo limit 5
tc qdisc del dev lo root
This is because in tcindex_set_parms, when there is no old_r, we set new
exts to cr.exts. And we didn't set it to filter when r == &new_filter_result.
Then in tcindex_delete() -> tcf_exts_get_net(), we will get NULL pointer
dereference as we didn't init exts.
Fix it by moving tcf_exts_change() after "if (old_r && old_r != r)" check.
Then we don't need "cr" as there is no errout after that.
Fixes: bf63ac73b3e13 ("net_sched: fix an oops in tcindex filter") Reported-by: Li Shuang <shuali@redhat.com> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Acked-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 2df8bee5654bb2b7312662ca6810d4dc16b0b67f) Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Joerg Roedel [Fri, 7 Jun 2019 17:47:27 +0000 (13:47 -0400)]
iommu/amd: Set exclusion range correctly
BugLink: https://bugs.launchpad.net/bugs/1823037
The exlcusion range limit register needs to contain the
base-address of the last page that is part of the range, as
bits 0-11 of this register are treated as 0xfff by the
hardware for comparisons.
So correctly set the exclusion range in the hardware to the
last page which is _in_ the range.
Fixes: b2026aa2dce44 ('x86, AMD IOMMU: add functions for programming IOMMU MMIO space') Signed-off-by: Joerg Roedel <jroedel@suse.de>
(cherry picked from commit 3c677d206210f53a4be972211066c0f1cd47fe12 ) Signed-off-by: Jeffrey Lane <jeffrey.lane@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
Joerg Roedel [Fri, 7 Jun 2019 17:47:26 +0000 (13:47 -0400)]
iommu/amd: Reserve exclusion range in iova-domain
BugLink: https://bugs.launchpad.net/bugs/1823037
If a device has an exclusion range specified in the IVRS
table, this region needs to be reserved in the iova-domain
of that device. This hasn't happened until now and can cause
data corruption on data transfered with these devices.
Treat exclusion ranges as reserved regions in the iommu-core
to fix the problem.
Fixes: be2a022c0dd0 ('x86, AMD IOMMU: add functions to parse IOMMU memory mapping requirements for devices') Signed-off-by: Joerg Roedel <jroedel@suse.de> Reviewed-by: Gary R Hook <gary.hook@amd.com>
(cherry picked from commit 8aafaaf2212192012f5bae305bb31cdf7681d777 ) Signed-off-by: Jeffrey Lane <jeffrey.lane@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
Colin Ian King [Wed, 19 Jun 2019 13:30:32 +0000 (14:30 +0100)]
mm/page_idle.c: fix oops because end_pfn is larger than max_pfn
BugLink: https://bugs.launchpad.net/bugs/1833410
Currently the calcuation of end_pfn can round up the pfn number to more
than the actual maximum number of pfns, causing an Oops. Fix this by
ensuring end_pfn is never more than max_pfn.
This can be easily triggered when on systems where the end_pfn gets
rounded up to more than max_pfn using the idle-page stress-ng stress test:
Link: http://lkml.kernel.org/r/20190618124352.28307-1-colin.king@canonical.com Fixes: 33c3fc71c8cf ("mm: introduce idle page tracking") Signed-off-by: Colin Ian King <colin.king@canonical.com>
(cherry picked from commit d96d6145d9796d5f1eac242538d45559e9a23404 linux-next) Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
(cherry picked from commit d96d6145d9796d5f1eac242538d45559e9a23404 linux-next) Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
Changbin Du [Tue, 11 Jun 2019 08:33:00 +0000 (10:33 +0200)]
drm/i915/gvt: Fix aperture read/write emulation when enable x-no-mmap=on
When add 'x-no-mmap=on' for vfio-pci option, aperture access in guest
is emulated. But the vgpu_aperture_rw() function take wrong offset when
do memcpy, since vgpu->gm.aperture_va is not the base of entire aperture.
This mistake cause GPU command in guest get lost and so the seqno is not
updated in engine HWSP.
This patch fix this, and it also move the emulation code to kvmgt.
Because only vfio need to emulate it. Put aperture rw to MMIO emulation
path breaks assumptions in xengt.
v2: Remove PAGE_ALIGN for size (zhenyu)
CVE-2019-11085
Fixes: f090a00df9ec ("drm/i915/gvt: Add emulation for BAR2 (aperture) with normal file RW approach") Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
(backported from commit d480b28a41a628e356dbacfa1c9f6d05b9baf838) Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Timo Aaltonen <tjaalton@ubuntu.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Matthew Auld [Tue, 11 Jun 2019 08:33:00 +0000 (10:33 +0200)]
drm/i915: make mappable struct resource centric
Now that we are using struct resource to track the stolen region, it is
more convenient if we track the mappable region in a resource as well.
v2: prefer iomap and gmadr naming scheme
prefer DEFINE_RES_MEM
CVE-2019-11085
Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171211151822.20953-8-matthew.auld@intel.com
(backported from commit 73ebd503034c1abe31137df02dd4493eb7a522d4) Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Timo Aaltonen <tjaalton@ubuntu.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Young Xiao [Fri, 7 Jun 2019 22:16:49 +0000 (15:16 -0700)]
Bluetooth: hidp: fix buffer overflow
CVE-2019-11884
Struct ca is copied from userspace. It is not checked whether the "name"
field is NULL terminated, which allows local users to obtain potentially
sensitive information from kernel stack memory, via a HIDPCONNADD command.
This vulnerability is similar to CVE-2011-1079.
Signed-off-by: Young Xiao <YangX92@hotmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org
(cherry picked from commit a1616a5ac99ede5d605047a9012481ce7ff18b16) Signed-off-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
Eric Biggers [Thu, 23 May 2019 05:09:00 +0000 (07:09 +0200)]
crypto: authenc - fix parsing key with misaligned rta_len
BugLink: https://bugs.launchpad.net/bugs/1829725
Keys for "authenc" AEADs are formatted as an rtattr containing a 4-byte
'enckeylen', followed by an authentication key and an encryption key.
crypto_authenc_extractkeys() parses the key to find the inner keys.
However, it fails to consider the case where the rtattr's payload is
longer than 4 bytes but not 4-byte aligned, and where the key ends
before the next 4-byte aligned boundary. In this case, 'keylen -=
RTA_ALIGN(rta->rta_len);' underflows to a value near UINT_MAX. This
causes a buffer overread and crash during crypto_ahash_setkey().
Fix it by restricting the rtattr payload to the expected size.
Tyler Hicks [Wed, 29 May 2019 02:28:00 +0000 (04:28 +0200)]
Documentation: Correct the possible MDS sysfs values
Adjust the last two rows in the table that display possible values when
MDS mitigation is enabled. They both were slightly innacurate.
In addition, convert the table of possible values and their descriptions
to a list-table. The simple table format uses the top border of equals
signs to determine cell width which resulted in the first column being
far too wide in comparison to the second column that contained the
majority of the text.
x86/mds: Add MDSUM variant to the MDS documentation
Updated the documentation for a new CVE-2019-11091 Microarchitectural Data
Sampling Uncacheable Memory (MDSUM) which is a variant of
Microarchitectural Data Sampling (MDS). MDS is a family of side channel
attacks on internal buffers in Intel CPUs.
MDSUM is a special case of MSBDS, MFBDS and MLPDS. An uncacheable load from
memory that takes a fault or assist can leave data in a microarchitectural
structure that may later be observed using one of the same methods used by
MSBDS, MFBDS or MLPDS. There are no new code changes expected for MDSUM.
The existing mitigation for MDS applies to MDSUM as well.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Tyler Hicks <tyhicks@canonical.com> Reviewed-by: Jon Masters <jcm@redhat.com>
CVE-2019-11091
(cherry picked from commit e672f8bf71c66253197e503f75c771dd28ada4a0) Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Tyler Hicks [Wed, 29 May 2019 02:28:00 +0000 (04:28 +0200)]
UBUNTU: SAUCE: Synchronize MDS mitigations with upstream
Bring the Ubuntu MDS mitigations in sync with the upstream mitigations.
The initial Ubuntu backport was based on the next to last revision of
the base patch series from upstream.
There is no functional change except for adjusting L1TF warning messages
to use the new URL for the L1TF admin guide.
The Atom Silvermont and Airmont changes in the cpu_vuln_whitelist[]
cause no functional changes because Silvermont and Airmont do not
support Intel Hyper-Threading. Therefore, even without this change, the
CPU buffers would be properly flushed as the CPU thread goes into sleep
state and MDS would be reported as being mitigated.
This commit contains changes from the following upstream commits:
5999bbe7a6ea ("Documentation: Add MDS vulnerability documentation") 65fd4cb65b2d ("Documentation: Move L1TF to separate directory") bc1241700acd ("x86/speculation/mds: Add mitigation control for MDS") 22dd8365088b ("x86/speculation/mds: Add mitigation mode VMWERV") e261f209c366 ("x86/speculation/mds: Add BUG_MSBDS_ONLY")
Zhenyu Wang [Wed, 29 May 2019 13:52:00 +0000 (15:52 +0200)]
drm/i915/gvt: Fix mmap range check
This is to fix missed mmap range check on vGPU bar2 region
and only allow to map vGPU allocated GMADDR range, which means
user space should support sparse mmap to get proper offset for
mmap vGPU aperture. And this takes care of actual pgoff in mmap
request as original code always does from beginning of vGPU
aperture.
Fixes: 659643f7d814 ("drm/i915/gvt/kvmgt: add vfio/mdev support to KVMGT") Cc: "Monroy, Rodrigo Axel" <rodrigo.axel.monroy@intel.com> Cc: "Orrala Contreras, Alfredo" <alfredo.orrala.contreras@intel.com> Cc: stable@vger.kernel.org # v4.10+ Reviewed-by: Hang Yuan <hang.yuan@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
CVE-2019-11085
(cherry picked from commit 51b00d8509dc69c98740da2ad07308b630d3eb7d) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Michael Ellerman [Tue, 14 May 2019 09:01:00 +0000 (11:01 +0200)]
selftests/powerpc: Remove Power9 copy_unaligned test
BugLink: https://bugs.launchpad.net/bugs/1813118
This is a test of the ISA 3.0 "copy" instruction. That instruction has
an L field, which if set to 1 specifies that "the instruction
identifies the beginning of a move group" (pp 858). That's also
referred to as "copy first" vs "copy".
In ISA 3.0B the copy instruction does not have an L field, and the
corresponding bit in the instruction must be set to 1.
This test is generating a "copy" instruction, not a "copy first", and
so on Power9 (which implements 3.0B), this results in an illegal
instruction.
So just drop the test entirely. We still have copy_first_unaligned to
test the "copy first" behaviour.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Acked-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 83039f22ba2f6aff935a2acbb6bf671374e8317d) Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1812796
Passing EPERM during syscall skipping was confusing since the test wasn't
actually exercising the errno evaluation -- it was just passing a literal
"1" (EPERM). Instead, expand the tests to check both direct value returns
(positive, 45000 in this case), and errno values (negative, -ESRCH in this
case) to check both fake success and fake failure during syscall skipping.
Reported-by: Colin Ian King <colin.king@canonical.com> Fixes: a33b2d0359a0 ("selftests/seccomp: Add tests for basic ptrace actions") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Shuah Khan <shuah@kernel.org>
(cherry picked from commit ed5f13261cb65b02c611ae9971677f33581d4286) Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Harish [Tue, 14 May 2019 06:57:00 +0000 (08:57 +0200)]
selftests/powerpc: Fix to use ucontext_t instead of struct ucontext
BugLink: https://bugs.launchpad.net/bugs/1828935
With glibc 2.26 'struct ucontext' is removed to improve POSIX
compliance, which breaks powerpc/alignment_handler selftest. Fix the
test by using ucontext_t. Tested on ppc, works with older glibc
versions as well.
Fixes the following:
alignment_handler.c: In function ‘sighandler’:
alignment_handler.c:68:5: error: dereferencing pointer to incomplete type ‘struct ucontext’
ucp->uc_mcontext.gp_regs[PT_NIP] += 4;
Signed-off-by: Harish <harish@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit ecdf06e1ea5376bba03c155751f6869d3dfaa210) Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
[mpe: Add 32-bit support to the signal handler] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit 8d1915873d492b8e1f03bbcab527db62a8d49542) Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Andrea Righi [Mon, 20 May 2019 09:46:00 +0000 (11:46 +0200)]
UBUNTU: SAUCE: (noup) Update zfs to 0.7.5-1ubuntu16.5
BugLink: https://bugs.launchpad.net/bugs/1828763
In b49151d684f44 tx_waited has been renamed to tx_dirty_delayed, but
only in the tracepoint definition (in trace_dmu.h) and not in the rest
of the code, causing build errors if zfs tracepoints are enabled.
Fix by reverting tx_dirty_delayed back to the original name tx_waited.
NOTE: this bug doesn't show up in regular builds, because zfs
tracepoints are not enabled by default.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Kailang Yang [Mon, 13 May 2019 11:48:00 +0000 (13:48 +0200)]
ALSA: hda/realtek - Fixup headphone noise via runtime suspend
BugLink: https://bugs.launchpad.net/bugs/1828798
Dell platform with ALC298.
system enter to runtime suspend. Headphone had noise.
Let Headset Mic not shutup will solve this issue.
[ Fixed minor coding style issues by tiwai ]
Signed-off-by: Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
(backported from commit dad3197da7a3817f27bb24f7fd3c135ffa707202) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-By: AceLan Kao <acelan.kao@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1828798
Dell Precision 5820 with ALC3234 codec (which is equivalent with
ALC255) shows click noises at (runtime) PM resume on the headphone.
The biggest source of the noise comes from the cleared headphone pin
control at resume, which is done via the standard shutup procedure.
Although we have an override of the standard shutup callback to
replace with NOP, this would skip other needed stuff (e.g. the pull
down of headset power). So, instead, this "fixes" the behavior of
alc_fixup_no_shutup() by introducing spec->no_shutup_pins flag.
When this flag is set, Realtek codec won't call the standard
snd_hda_shutup_pins() & co. Now alc_fixup_no_shutup() just sets this
flag instead of overriding spec->shutup callback itself. This allows
us to apply the similar fix for other entries easily if needed in
future.
Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
(backported from commit c0ca5eced22215c1e03e3ad479f8fab0bbb30772) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-By: AceLan Kao <acelan.kao@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
The library will be installed on the linux-tools package the same way other
tools are installed. That allows a user to use the current kernel version
as given by `uname -r` to find the library at
/usr/lib/linux-tools/`uname -r`/libperf-jvmti.so, which will be a symlink
to a version-specific library.
This requires arches and derivatives to opt in with do_tools_perf_jvmti.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Andy Whitcroft <apw@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
While a socket is being closed, it is very possible other
threads find it in rtnetlink dump.
tcp_get_info() will acquire the socket lock for a short amount
of time (slow = lock_sock_fast(sk)/unlock_sock_fast(sk, slow);),
enough to trigger the warning.
Fixes: 67db3e4bfbc9 ("tcp: no longer hold ehash lock while calling tcp_get_info()") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 8873c064d1de579ea23412a6d3eee972593f142b) Signed-off-by: Ioanna Alifieraki <ioanna-maria.alifieraki@canonical.com> Acked-by: Khalid Elmously <khalid.elmously@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
As user-supplied nladdr->nl_groups is __u32, it's possible to subscribe
only to first 32 groups.
The check for correctness of .bind() userspace supplied parameter
is done by applying mask made from ngroups shift. Which broke Android
as they have 64 groups and the shift for mask resulted in an overflow.
Fixes: 61f4b23769f0 ("netlink: Don't shift with UB on nlk->ngroups") Cc: "David S. Miller" <davem@davemloft.net> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: netdev@vger.kernel.org Cc: stable@vger.kernel.org Reported-and-Tested-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Dmitry Safonov <dima@arista.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 91874ecf32e41b5d86a4cb9d60e0bee50d828058) Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
Andy Shevchenko [Thu, 23 May 2019 08:00:25 +0000 (16:00 +0800)]
mfd: intel-lpss: Add Intel Comet Lake PCI IDs
BugLink: https://bugs.launchpad.net/bugs/1830175
Intel Comet Lake has the same LPSS than Intel Cannon Lake.
Add the new IDs to the list of supported devices.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Tested-by: Evan Green <evgreen@chromium.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
(cherry picked from commit dd6629073a97e5ee125eacbd22eea62281891c67) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: AceLan Kao <acelan.kao@canonical.com> Acked-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
This is because the kernel checks the NAPI polling weights
requested by drivers and it prints an error message if a driver
requests a weight bigger than 64.
So use NAPI_POLL_WEIGHT to fix it.
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com> Signed-off-by: Peng Li <lipeng321@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit acb1ce15a61154aa501891d67ebf79bc9ea26818) Signed-off-by: Ike Panhc <ike.pan@canonical.com> Acked-by: Khalid Elmously <khalid.elmously@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
Woods, Brian [Tue, 6 Nov 2018 20:08:16 +0000 (20:08 +0000)]
x86/amd_nb: Add support for newer PCI topologies
BugLink: https://bugs.launchpad.net/bugs/1819485
Add support for new processors which have multiple PCI root complexes
per data fabric/system management network interface. If there are (N)
multiple PCI roots per DF/SMN interface, then the PCI roots are
redundant (as far as SMN/DF access goes). For each DF/SMN interface:
map to the first available PCI root and skip the next N-1 PCI roots so
the following DF/SMN interface get mapped to a correct PCI root.
Borislav Petkov [Tue, 27 Nov 2018 13:41:37 +0000 (14:41 +0100)]
x86/MCE/AMD: Fix the thresholding machinery initialization order
BugLink: https://bugs.launchpad.net/bugs/1819485
Currently, the code sets up the thresholding interrupt vector and only
then goes about initializing the thresholding banks. Which is wrong,
because an early thresholding interrupt would cause a NULL pointer
dereference when accessing those banks and prevent the machine from
booting.
Therefore, set the thresholding interrupt vector only *after* having
initialized the banks successfully.
Fixes: 18807ddb7f88 ("x86/mce/AMD: Reset Threshold Limit after logging error") Reported-by: Rafał Miłecki <rafal@milecki.pl> Reported-by: John Clemens <clemej@gmail.com> Signed-off-by: Borislav Petkov <bp@suse.de> Tested-by: Rafał Miłecki <rafal@milecki.pl> Tested-by: John Clemens <john@deater.net> Cc: Aravind Gopalakrishnan <aravindksg.lkml@gmail.com> Cc: linux-edac@vger.kernel.org Cc: stable@vger.kernel.org Cc: Tony Luck <tony.luck@intel.com> Cc: x86@kernel.org Cc: Yazen Ghannam <Yazen.Ghannam@amd.com> Link: https://lkml.kernel.org/r/20181127101700.2964-1-zajec5@gmail.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=201291
(cherry picked from commit 60c8144afc287ef09ce8c1230c6aa972659ba1bb) Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Khalid Elmously <khalid.elmously@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
Woods, Brian [Tue, 6 Nov 2018 20:08:18 +0000 (20:08 +0000)]
x86/amd_nb: Add PCI device IDs for family 17h, model 30h
BugLink: https://bugs.launchpad.net/bugs/1819485
Add the PCI device IDs for family 17h model 30h, since they are needed
for accessing various registers via the data fabric/SMN interface.
Signed-off-by: Brian Woods <brian.woods@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> CC: Bjorn Helgaas <bhelgaas@google.com> CC: Clemens Ladisch <clemens@ladisch.de> CC: Guenter Roeck <linux@roeck-us.net> CC: "H. Peter Anvin" <hpa@zytor.com> CC: Ingo Molnar <mingo@redhat.com> CC: Jean Delvare <jdelvare@suse.com> CC: Jia Zhang <qianyue.zj@alibaba-inc.com> CC: <linux-hwmon@vger.kernel.org> CC: <linux-pci@vger.kernel.org> CC: Pu Wen <puwen@hygon.cn> CC: Thomas Gleixner <tglx@linutronix.de> CC: x86-ml <x86@kernel.org> Link: http://lkml.kernel.org/r/20181106200754.60722-4-brian.woods@amd.com
(cherry picked from commit be3518a16ef270e3b030a6ae96055f83f51bd3dd) Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Khalid Elmously <khalid.elmously@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
Woods, Brian [Tue, 6 Nov 2018 20:08:21 +0000 (20:08 +0000)]
hwmon/k10temp: Add support for AMD family 17h, model 30h CPUs
BugLink: https://bugs.launchpad.net/bugs/1819485
Add support for AMD family 17h model 30h processors for k10temp. Model
30h is functionally the same as model 01h processors (as far as k10temp
is concerned), just the PCI device IDs need to be updated.
Signed-off-by: Brian Woods <brian.woods@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Guenter Roeck <linux@roeck-us.net> CC: Bjorn Helgaas <bhelgaas@google.com> CC: Clemens Ladisch <clemens@ladisch.de> CC: "H. Peter Anvin" <hpa@zytor.com> CC: Ingo Molnar <mingo@redhat.com> CC: Jean Delvare <jdelvare@suse.com> CC: Jia Zhang <qianyue.zj@alibaba-inc.com> CC: <linux-hwmon@vger.kernel.org> CC: <linux-pci@vger.kernel.org> CC: Pu Wen <puwen@hygon.cn> CC: Thomas Gleixner <tglx@linutronix.de> CC: x86-ml <x86@kernel.org> Link: http://lkml.kernel.org/r/20181106200754.60722-5-brian.woods@amd.com
(cherry picked from commit 210ba1201ff950b3d05bfd8fa5d47540cea393c0) Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Khalid Elmously <khalid.elmously@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1819485
Consolidate shared PCI_DEVICE_IDs that were scattered through k10temp
and amd_nb, and move them into pci_ids.
Signed-off-by: Brian Woods <brian.woods@amd.com> Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Guenter Roeck <linux@roeck-us.net> CC: Bjorn Helgaas <bhelgaas@google.com> CC: Clemens Ladisch <clemens@ladisch.de> CC: "H. Peter Anvin" <hpa@zytor.com> CC: Ingo Molnar <mingo@redhat.com> CC: Jean Delvare <jdelvare@suse.com> CC: Jia Zhang <qianyue.zj@alibaba-inc.com> CC: <linux-hwmon@vger.kernel.org> CC: <linux-pci@vger.kernel.org> CC: Pu Wen <puwen@hygon.cn> CC: Thomas Gleixner <tglx@linutronix.de> CC: x86-ml <x86@kernel.org> Link: http://lkml.kernel.org/r/20181106200754.60722-2-brian.woods@amd.com
(cherry picked from commit dedf7dce4cec5c0abe69f4fa6938d5100398220b) Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Khalid Elmously <khalid.elmously@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1819485
The AMD IOMMU XT mode enables interrupt remapping with 32-bit destination
APIC ID, which is required for x2APIC. The feature is available when
the XTSup bit is set in the IOMMU Extended Feature register
and/or the IVHD Type 10h IOMMU Feature Reporting field.
For more information, please see section "IOMMU x2APIC Support" of
the AMD I/O Virtualization Technology (IOMMU) Specification.
iommu/amd: Add support for higher 64-bit IOMMU Control Register
BugLink: https://bugs.launchpad.net/bugs/1819485
Currently, the driver only supports lower 32-bit of IOMMU Control register.
However, newer AMD IOMMU specification has extended this register
to 64-bit. Therefore, replace the accessing API with the 64-bit version.
BugLink: https://bugs.launchpad.net/bugs/1819485
The enum is currently defined in Intel-specific DMAR header file,
but it is also used by APIC common code. Therefore, move it to
a more appropriate interrupt-remapping common header file.
This will also be used by subsequent patches.
Haren Myneni [Wed, 22 May 2019 17:13:08 +0000 (12:13 -0500)]
crypto/nx: Initialize 842 high and normal RxFIFO control registers
BugLink: https://bugs.launchpad.net/bugs/1827755
NX increments readOffset by FIFO size in receive FIFO control register
when CRB is read. But the index in RxFIFO has to match with the
corresponding entry in FIFO maintained by VAS in kernel. Otherwise NX
may be processing incorrect CRBs and can cause CRB timeout.
VAS FIFO offset is 0 when the receive window is opened during
initialization. When the module is reloaded or in kexec boot, readOffset
in FIFO control register may not match with VAS entry. This patch adds
nx_coproc_init OPAL call to reset readOffset and queued entries in FIFO
control register for both high and normal FIFOs.
BugLink: https://bugs.launchpad.net/bugs/1829972
Right now the early machine detection code check stsi 3.2.2 for "KVM"
and set MACHINE_IS_VM if this is different. As the console detection
uses diagnose 8 if MACHINE_IS_VM returns true this will crash Linux
early for any non z/VM system that sets a different value than KVM.
So instead of assuming z/VM, do not set any of MACHINE_IS_LPAR,
MACHINE_IS_VM, or MACHINE_IS_KVM.
CC: stable@vger.kernel.org Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
(cherry picked from commit 03aa047ef2db4985e444af6ee1c1dd084ad9fb4c) Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by: Khalid Elmously <khalid.elmously@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
Eric Dumazet [Fri, 21 Jun 2019 13:09:55 +0000 (06:09 -0700)]
tcp: refine memory limit test in tcp_fragment()
tcp_fragment() might be called for skbs in the write queue.
Memory limits might have been exceeded because tcp_sendmsg() only
checks limits at full skb (64KB) boundaries.
Therefore, we need to make sure tcp_fragment() wont punish applications
that might have setup very low SO_SNDBUF values.
Fixes: f070ef2ac667 ("tcp: tcp_fragment() should apply sane memory limits") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Christoph Paasch <cpaasch@apple.com> Tested-by: Christoph Paasch <cpaasch@apple.com> Signed-off-by: David S. Miller <davem@davemloft.net> BugLink: https://bugs.launchpad.net/bugs/1831638
CVE-2019-11478
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Eric Dumazet [Sat, 8 Jun 2019 17:38:07 +0000 (10:38 -0700)]
UBUNTU: SAUCE: tcp: add tcp_min_snd_mss sysctl
Some TCP peers announce a very small MSS option in their SYN and/or
SYN/ACK messages.
This forces the stack to send packets with a very high network/cpu
overhead.
Linux has enforced a minimal value of 48. Since this value includes
the size of TCP options, and that the options can consume up to 40
bytes, this means that each segment can include only 8 bytes of payload.
In some cases, it can be useful to increase the minimal value
to a saner value.
We still let the default to 48 (TCP_MIN_SND_MSS), for compatibility
reasons.
Note that TCP_MAXSEG socket option enforces a minimal value
of (TCP_MIN_MSS). David Miller increased this minimal value
in commit c39508d6f118 ("tcp: Make TCP_MAXSEG minimum more correct.")
from 64 to 88.
We might in the future merge TCP_MIN_SND_MSS and TCP_MIN_MSS.
Signed-off-by: Eric Dumazet <edumazet@google.com> Suggested-by: Jonathan Looney <jtl@netflix.com> Cc: Neal Cardwell <ncardwell@google.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Tyler Hicks <tyhicks@canonical.com> Cc: Bruce Curtis <brucec@netflix.com> Cc: Jonathan Lemon <jonathan.lemon@gmail.com>
CVE-2019-11479
Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Eric Dumazet [Fri, 31 May 2019 20:59:30 +0000 (20:59 +0000)]
UBUNTU: SAUCE: tcp: tcp_fragment() should apply sane memory limits
Jonathan Looney reported that a malicious peer can force a sender
to fragment its retransmit queue into tiny skbs, inflating memory
usage and/or overflow 32bit counters.
TCP allows an application to queue up to sk_sndbuf bytes,
so we need to give some allowance for non malicious splitting
of retransmit queue.
A new SNMP counter is added to monitor how many times TCP
did not allow to split an skb if the allowance was exceeded.
Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Jonathan Looney <jtl@netflix.com> Cc: Bruce Curtis <brucec@netflix.com> Cc: Neal Cardwell <ncardwell@google.com> CC: Yuchung Cheng <ycheng@google.com> BugLink: https://bugs.launchpad.net/bugs/1831638
[tyhicks: Adjust context of SNMP enums] Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Eric Dumazet [Fri, 31 May 2019 20:59:27 +0000 (20:59 +0000)]
UBUNTU: SAUCE: tcp: limit payload size of sacked skbs
Jonathan Looney reported that TCP can trigger the following crash
in tcp_shifted_skb() :
BUG_ON(tcp_skb_pcount(skb) < pcount);
This can happen if the remote peer has advertized the smallest
MSS that linux TCP accepts : 48
An skb can hold 17 fragments, and each fragment can hold 32KB
on x86, or 64KB on PowerPC.
This means that the 16bit witdh of TCP_SKB_CB(skb)->tcp_gso_segs
can overflow.
Note that tcp_sendmsg() builds skbs with less than 64KB
of payload, so this problem needs SACK to be enabled.
SACK blocks allow TCP to coalesce multiple skbs in the retransmit
queue, thus filling the 17 fragments to maximal capacity.
Fixes: 832d11c5cd07 ("tcp: Try to restore large SKBs while SACK processing") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: Jonathan Looney <jtl@netflix.com> Acked-by: Neal Cardwell <ncardwell@google.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Bruce Curtis <brucec@netflix.com> BugLink: https://bugs.launchpad.net/bugs/1831637 Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
Tyler Hicks [Wed, 27 Mar 2019 17:45:13 +0000 (17:45 +0000)]
UBUNTU: [Config] Disable a.out support
BugLink: https://launchpad.net/bugs/1818552
The a.out core dump handler is broken and will be removed in 5.1 with
upstream commit 08300f4402ab ("a.out: remove core dumping support").
Additionally, all a.out support will be deprecated in 5.1 with upstream
commit eac616557050 ("x86: Deprecate a.out support") and completely
removed in a future release.
Disable it in Ubuntu since it is risky to leave enabled and there are
likely no users that depend on it.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-By: You-Sheng Yang <vicamo.yang@canonical.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Julian Wiedmann [Thu, 9 May 2019 15:36:00 +0000 (17:36 +0200)]
s390/qdio: clear intparm during shutdown
BugLink: https://bugs.launchpad.net/bugs/1828394
During shutdown, qdio returns its ccw device back to control by the
upper-layer driver. But there is a remote chance that by the time where the
IRQ handler gets switched back, the interrupt for the preceding
ccw_device_{clear,halt} hasn't been presented yet.
Upper-layer drivers would then need to handle this IRQ - and since the IO
is issued with an intparm, it could very well be confused with whatever
intparm mechanism the driver uses itself (eg intparm == request address).
So when switching over the IRQ handler, also clear the intparm and have
upper-layer drivers deal with any such delayed interrupt as if it was
unsolicited.
Suggested-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
(cherry picked from commit 89286320a236d245834075fa13adb0bdd827ecaa) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
kprobes/x86: Fix instruction patching corruption when copying more than one RIP-relative instruction
BugLink: https://bugs.launchpad.net/bugs/1826385
After copy_optimized_instructions() copies several instructions
to the working buffer it tries to fix up the real RIP address, but it
adjusts the RIP-relative instruction with an incorrect RIP address
for the 2nd and subsequent instructions due to a bug in the logic.
This will break the kernel pretty badly (with likely outcomes such as
a kernel freeze, a crash, or worse) because probed instructions can refer
to the wrong data.
For example putting kprobes on cpumask_next() typically hits this bug.
cpumask_next() is normally like below if CONFIG_CPUMASK_OFFSTACK=y
(in this case nr_cpumask_bits is an alias of nr_cpu_ids):
This dump shows that the second MOV accesses *(nr_cpu_ids+3) instead of
the original *nr_cpu_ids. This leads to a kernel freeze because
cpumask_next() always returns 0 and for_each_cpu() never ends.
Fix this by adding 'len' correctly to the real RIP address while
copying.
[ mingo: Improved the changelog. ]
Reported-by: Michael Rodin <michael@rodin.online> Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org # v4.15+ Fixes: 63fef14fc98a ("kprobes/x86: Make insn buffer always ROX and use text_poke()") Link: http://lkml.kernel.org/r/153504457253.22602.1314289671019919596.stgit@devbox Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit 43a1b0cb4cd6dbfd3cd9c10da663368394d299d8) Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Kleber Souza <kleber.souza@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
UBUNTU: [Config] Update config for AMD MP2 I2C driver
BugLink: https://bugs.launchpad.net/bugs/1787775
The new MP2 driver can work as module instead of builtin.
Also this chip is part of Raven Ridge SoC, so it's only used on amd64.
MP2 controllers have two separate busses, so may accommodate up to two I2C
adapters. Those adapters are listed in the ACPI namespace with the
"AMDI0011" HID, and probed by a platform driver.
Communication with the MP2 takes place through MMIO registers, or through
DMA for more than 32 bytes transfers.
This is major rework of the patch submitted by Nehal-bakulchandra Shah from
AMD (https://patchwork.kernel.org/patch/10597369/).
Most of the event handling of v3 was rewritten to make it work with more
than one bus (e.g on Ryzen-based Lenovo Yoga 530), and this version
contains many other improvements.
Make sure we report 'no buffer' for 0-length messages. This can only
happen if threshold is set to 0 which is kind of bogus but we should
still handle this situation. Update the docs and add a debug message
to educate callers of this function.
Reported-by: Hsin-Yi Wang <hsinyi@chromium.org> Fixes: e94bc5d18be0 ("i2c: add helpers to ease DMA handling") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
(cherry picked from commit bf263c35b2ebe7f1674205f6b36487250299b5a7) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Khalid Elmously <khalid.elmously@canonical.com> Acked-by: Kleber Souza <kleber.souza@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
I2C has no requirement that the buffer of a message needs to be DMA
safe. In case it is, it can now be flagged, so drivers wishing to
do DMA can use the buffer directly.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
(cherry picked from commit 521a72e1f2e8141d78e7699eaacda24e308ed428) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Khalid Elmously <khalid.elmously@canonical.com> Acked-by: Kleber Souza <kleber.souza@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
One helper checks if DMA is suitable and optionally creates a bounce
buffer, if not. The other function returns the bounce buffer and makes
sure the data is properly copied back to the message.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
(cherry picked from commit e94bc5d18be03dac8e9d73d30c5523728edeff76) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Khalid Elmously <khalid.elmously@canonical.com> Acked-by: Kleber Souza <kleber.souza@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>
selftests/powerpc: Skip tm-unavailable if TM is not enabled
BugLink: https://bugs.launchpad.net/bugs/1813129
Some processor revisions do not support transactional memory, and
additionally kernel support can be disabled. In either case the
tm-unavailable test should be skipped, otherwise it will fail with
a SIGILL.
That commit also sets this selftest to be called through the test
harness as it's done for other TM selftests.
Finally, it avoids using "ping" as a thread name since it's
ambiguous and can be confusing when shown, for instance,
in a kernel backtrace log.
Fixes: 77fad8bfb1d2 ("selftests/powerpc: Check FP/VEC on exception in TM") Signed-off-by: Gustavo Romero <gromero@linux.vnet.ibm.com> Reviewed-by: Cyril Bur <cyrilbur@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from commit b395e55b49ecd56ea28dc629f4ca4c6239fc07c3) Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by: Connor Kuehl <connor.kuehl@canonical.com> Acked-by: Kleber Souza <kleber.souza@canonical.com> Signed-off-by: Khalid Elmously <khalid.elmously@canonical.com>