4.9.45-stable review
Greg Kroah-Hartman
maintainercover 4.9.45-stable review
This is the start of the stable review cycle for the 4.9.45 release. There are 27 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu Aug 24 19:13:17 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.45-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.9.45-rc1
Hector Martin <[email protected]>
usb: qmi_wwan: add D-Link DWM-222 device ID
Mathias Nyman <[email protected]>
usb: optimize acpi companion search for usb port devices
Oleg Nesterov <[email protected]>
pids: make task_tgid_nr_ns() safe
Linus Torvalds <[email protected]>
Sanitize 'move_pages()' permission checks
Alexey Dobriyan <[email protected]>
genirq/ipi: Fixup checks against nr_cpu_ids
Marc Zyngier <[email protected]>
genirq: Restore trigger settings in irq_modify_status()
Boris Brezillon <[email protected]>
irqchip/atmel-aic: Fix unbalanced refcount in aic_common_rtc_irq_fixup()
Boris Brezillon <[email protected]>
irqchip/atmel-aic: Fix unbalanced of_node_put() in aic_common_irq_fixup()
Andy Lutomirski <[email protected]>
x86/asm/64: Clear AC on NMI entries
Munehisa Kamata <[email protected]>
xen-blkfront: use a right index when checking requests
Benjamin Herrenschmidt <[email protected]>
powerpc: Fix VSX enabling/flushing to also test MSR_FP and MSR_VEC
Christoph Hellwig <[email protected]>
blk-mq-pci: add a fallback when pci_irq_get_affinity returns NULL
Roger Pau Monne <[email protected]>
xen: fix bio vec merging
Kees Cook <[email protected]>
mm: revert x86_64 and arm64 ELF_ET_DYN_BASE base changes
zhong jiang <[email protected]>
mm/mempolicy: fix use after free when calling get_mempolicy
Michal Hocko <[email protected]>
mm: fix double mmap_sem unlock on MMF_UNSTABLE enforced SIGBUS
Pavel Tatashin <[email protected]>
mm: discard memblock data later
Takashi Iwai <[email protected]>
ALSA: usb-audio: Add mute TLV for playback volumes on C-Media devices
Takashi Iwai <[email protected]>
ALSA: usb-audio: Apply sample rate quirk to Sennheiser headset
Daniel Mentz <[email protected]>
ALSA: seq: 2nd attempt at fixing race creating a queue
KT Liao <[email protected]>
Input: elan_i2c - Add antoher Lenovo ACPI ID for upcoming Lenovo NB
Kai-Heng Feng <[email protected]>
Input: elan_i2c - add ELAN0608 to the ACPI table
[email protected] <[email protected]>
crypto: x86/sha1 - Fix reads beyond the number of blocks passed
Herbert Xu <[email protected]>
crypto: ixp4xx - Fix error handling path in 'aead_perform()'
Thomas Bogendoerfer <[email protected]>
parisc: pci memory bar assignment fails with 64bit kernels on dino/cujo
Jan Kara <[email protected]>
audit: Fix use after free in audit_remove_watch_rule()
Liping Zhang <[email protected]>
netfilter: nf_ct_ext: fix possible panic after nf_ct_extend_unregister
-------------
Diffstat:
Makefile | 4 +- arch/arm64/include/asm/elf.h | 4 +- arch/powerpc/kernel/process.c | 5 ++- arch/x86/crypto/sha1_avx2_x86_64_asm.S | 67 ++++++++++++++++++---------------- arch/x86/crypto/sha1_ssse3_glue.c | 2 +- arch/x86/entry/entry_64.S | 2 + arch/x86/include/asm/elf.h | 4 +- block/blk-mq-pci.c | 8 +++- drivers/block/xen-blkfront.c | 6 +-- drivers/crypto/ixp4xx_crypto.c | 6 +-- drivers/input/mouse/elan_i2c_core.c | 4 ++ drivers/irqchip/irq-atmel-aic-common.c | 5 +-- drivers/net/usb/qmi_wwan.c | 1 + drivers/parisc/dino.c | 2 +- drivers/usb/core/usb-acpi.c | 26 +++++++++++-- drivers/xen/biomerge.c | 3 +- include/linux/memblock.h | 6 ++- include/linux/pid.h | 4 +- include/linux/sched.h | 50 +++++++++++++------------ kernel/audit_watch.c | 12 +++--- kernel/irq/chip.c | 10 ++++- kernel/irq/ipi.c | 4 +- kernel/pid.c | 11 ++---- mm/memblock.c | 38 +++++++++---------- mm/memory.c | 12 +++++- mm/mempolicy.c | 5 --- mm/migrate.c | 11 ++---- mm/nobootmem.c | 16 -------- mm/page_alloc.c | 4 ++ net/netfilter/nf_conntrack_extend.c | 13 +++++-- sound/core/seq/seq_clientmgr.c | 13 ++----- sound/core/seq/seq_queue.c | 14 ++++--- sound/core/seq/seq_queue.h | 2 +- sound/usb/mixer.c | 2 + sound/usb/mixer.h | 1 + sound/usb/mixer_quirks.c | 6 +++ sound/usb/quirks.c | 1 + 37 files changed, 217 insertions(+), 167 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/27 netfilter: nf_ct_ext: fix possible panic after nf_ct_extend_unregister
4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liping Zhang <[email protected]>
commit 9c3f3794926a997b1cab6c42480ff300efa2d162 upstream.
If one cpu is doing nf_ct_extend_unregister while another cpu is doing __nf_ct_ext_add_length, then we may hit BUG_ON(t == NULL). Moreover, there's no synchronize_rcu invocation after set nf_ct_ext_types[id] to NULL, so it's possible that we may access invalid pointer.
But actually, most of the ct extends are built-in, so the problem listed above will not happen. However, there are two exceptions: NF_CT_EXT_NAT and NF_CT_EXT_SYNPROXY.
For _EXT_NAT, the panic will not happen, since adding the nat extend and unregistering the nat extend are located in the same file(nf_nat_core.c), this means that after the nat module is removed, we cannot add the nat extend too.
For _EXT_SYNPROXY, synproxy extend may be added by init_conntrack, while synproxy extend unregister will be done by synproxy_core_exit. So after nf_synproxy_core.ko is removed, we may still try to add the synproxy extend, then kernel panic may happen.
I know it's very hard to reproduce this issue, but I can play a tricky game to make it happen very easily :)
Step 1. Enable SYNPROXY for tcp dport 1234 at FORWARD hook:
# iptables -I FORWARD -p tcp --dport 1234 -j SYNPROXY
Step 2. Queue the syn packet to the userspace at raw table OUTPUT hook.
Also note, in the userspace we only add a 20s' delay, then
reinject the syn packet to the kernel:
# iptables -t raw -I OUTPUT -p tcp --syn -j NFQUEUE --queue-num 1
Step 3. Using "nc 2.2.2.2 1234" to connect the server.
Step 4. Now remove the nf_synproxy_core.ko quickly:
# iptables -F FORWARD
# rmmod ipt_SYNPROXY
# rmmod nf_synproxy_core
Step 5. After 20s' delay, the syn packet is reinjected to the kernel.Now you will see the panic like this:
kernel BUG at net/netfilter/nf_conntrack_extend.c:91!
Call Trace: ? __nf_ct_ext_add_length+0x53/0x3c0 [nf_conntrack] init_conntrack+0x12b/0x600 [nf_conntrack] nf_conntrack_in+0x4cc/0x580 [nf_conntrack] ipv4_conntrack_local+0x48/0x50 [nf_conntrack_ipv4] nf_reinject+0x104/0x270 nfqnl_recv_verdict+0x3e1/0x5f9 [nfnetlink_queue] ? nfqnl_recv_verdict+0x5/0x5f9 [nfnetlink_queue] ? nla_parse+0xa0/0x100 nfnetlink_rcv_msg+0x175/0x6a9 [nfnetlink] [...]
One possible solution is to make NF_CT_EXT_SYNPROXY extend built-in, i.e. introduce nf_conntrack_synproxy.c and only do ct extend register and unregister in it, similar to nf_conntrack_timeout.c.
But having such a obscure restriction of nf_ct_extend_unregister is not a good idea, so we should invoke synchronize_rcu after set nf_ct_ext_types to NULL, and check the NULL pointer when do __nf_ct_ext_add_length. Then it will be easier if we add new ct extend in the future.
Last, we use kfree_rcu to free nf_ct_ext, so rcu_barrier() is unnecessary anymore, remove it too.
--- net/netfilter/nf_conntrack_extend.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
net/netfilter/nf_conntrack_extend.c +10 -3
@@ -53,7 +53,11 @@ nf_ct_ext_create(struct nf_ct_ext **ext,rcu_read_lock (); t =rcu_dereference (nf_ct_ext_types[id]); -BUG_ON (t ==NULL ); +if (!t) { +rcu_read_unlock (); +return NULL ; + } + off =ALIGN (sizeof (struct nf_ct_ext ), t->align); len = off + t->len + var_alloc_len; alloc_size = t->alloc_size + var_alloc_len;
@@ -88,7 +92,10 @@ void *__nf_ct_ext_add_length(struct nf_crcu_read_lock (); t =rcu_dereference (nf_ct_ext_types[id]); -BUG_ON (t ==NULL ); +if (!t) { +rcu_read_unlock (); +return NULL ; + } newoff =ALIGN (old->len, t->align); newlen = newoff + t->len + var_alloc_len;
@@ -175,6 +182,6 @@ void nf_ct_extend_unregister(struct nf_cRCU_INIT_POINTER (nf_ct_ext_types[type->id],NULL );update_alloc_size (type);mutex_unlock (&nf_ct_ext_type_mutex); -rcu_barrier ();/* Wait for completion of call_rcu()'s */ +synchronize_rcu (); }EXPORT_SYMBOL_GPL (nf_ct_extend_unregister);
Greg Kroah-Hartman
maintainerPATCH 2/27 audit: Fix use after free in audit_remove_watch_rule()
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jan Kara <[email protected]>
commit d76036ab47eafa6ce52b69482e91ca3ba337d6d6 upstream.
audit_remove_watch_rule() drops watch's reference to parent but then continues to work with it. That is not safe as parent can get freed once we drop our reference. The following is a trivial reproducer:
mount -o loop image /mnt
touch /mnt/file
auditctl -w /mnt/file -p wax
umount /mnt
auditctl -D
<crash in fsnotify_destroy_mark()>
Grab our own reference in audit_remove_watch_rule() earlier to make sure mark does not get freed under us.
--- kernel/audit_watch.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
kernel/audit_watch.c +7 -5
@@ -457,13 +457,15 @@ void audit_remove_watch_rule(struct audilist_del (&krule->rlist);if (list_empty (&watch->rules)) { +/* +* audit_remove_watch() drops our reference to 'parent' which +* can get freed. Grab our own reference to be safe. +*/ +audit_get_parent (parent);audit_remove_watch (watch); - -if (list_empty (&parent->watches)) { -audit_get_parent (parent); +if (list_empty (&parent->watches))fsnotify_destroy_mark (&parent->mark, audit_watch_group); -audit_put_parent (parent); - } +audit_put_parent (parent); } }
Greg Kroah-Hartman
maintainerPATCH 3/27 parisc: pci memory bar assignment fails with 64bit kernels on dino/cujo
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Bogendoerfer <[email protected]>
commit 4098116039911e8870d84c975e2ec22dab65a909 upstream.
For 64bit kernels the lmmio_space_offset of the host bridge window isn't set correctly on systems with dino/cujo PCI host bridges. This leads to not assigned memory bars and failing drivers, which need to use these bars.
--- drivers/parisc/dino.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/parisc/dino.c +1 -1
@@ -956,7 +956,7 @@ static int __init dino_probe(struct pari dino_dev->hba.dev = dev; dino_dev->hba.base_addr =ioremap_nocache (hpa,4096 ); - dino_dev->hba.lmmio_space_offset =0 ;/* CPU addrs == bus addrs */ + dino_dev->hba.lmmio_space_offset =PCI_F_EXTEND ;spin_lock_init (&dino_dev->dinosaur_pen); dino_dev->hba.iommu =ccio_get_iommu (dev);
Greg Kroah-Hartman
maintainerPATCH 4/27 crypto: ixp4xx - Fix error handling path in aead_perform()
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Herbert Xu <[email protected]>
commit 28389575a8cf933a5f3c378556b9f4d3cce0efd2 upstream.
In commit 0f987e25cb8a, the source processing has been moved in front of the destination processing, but the error handling path has not been modified accordingly.
Free resources in the correct order to avoid some leaks.
--- drivers/crypto/ixp4xx_crypto.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/crypto/ixp4xx_crypto.c +3 -3
@@ -1074,7 +1074,7 @@ static int aead_perform(struct aead_requ req_ctx->hmac_virt =dma_pool_alloc (buffer_pool, flags, &crypt->icv_rev_aes);if (unlikely (!req_ctx->hmac_virt)) - goto free_buf_src; + goto free_buf_dst;if (!encrypt) {scatterwalk_map_and_copy (req_ctx->hmac_virt, req->src, cryptlen, authsize,0 );
@@ -1089,10 +1089,10 @@ static int aead_perform(struct aead_requBUG_ON (qmgr_stat_overflow (SEND_QID ));return -EINPROGRESS ; -free_buf_src: -free_buf_chain (dev, req_ctx->src, crypt->src_buf); free_buf_dst:free_buf_chain (dev, req_ctx->dst, crypt->dst_buf); +free_buf_src: +free_buf_chain (dev, req_ctx->src, crypt->src_buf); crypt->ctl_flags =CTL_FLAG_UNUSED ;return -ENOMEM ; }
Greg Kroah-Hartman
maintainerPATCH 5/27 crypto: x86/sha1 - Fix reads beyond the number of blocks passed
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: [email protected] <[email protected]>
commit 8861249c740fc4af9ddc5aee321eafefb960d7c6 upstream.
It was reported that the sha1 AVX2 function(sha1_transform_avx2) is reading ahead beyond its intended data, and causing a crash if the next block is beyond page boundary:
http://marc.info/?l=linux-crypto-vger&m=149373371023377
This patch makes sure that there is no overflow for any buffer length.
It passes the tests written by Jan Stancek that revealed this problem:
https://github.com/jstancek/sha1-avx2-crash
I have re-enabled sha1-avx2 by reverting commitb82ce24426a4071da9529d726057e4e642948667
--- arch/x86/crypto/sha1_avx2_x86_64_asm.S | 67 +++++++++++++++++---------------- arch/x86/crypto/sha1_ssse3_glue.c | 2 2 files changed, 37 insertions(+), 32 deletions(-)
arch/x86/crypto/sha1_avx2_x86_64_asm.S +36 -31
@@ -117,11 +117,10 @@ .set T1, REG_T1 .endm -#define K_BASE %r8 #define HASH_PTR %r9 +#define BLOCKS_CTR %r8 #define BUFFER_PTR %r10 #define BUFFER_PTR2 %r13 -#define BUFFER_END %r11 #define PRECALC_BUF %r14 #define WK_BUF %r15
@@ -205,14 +204,14 @@ * blended AVX2 and ALU instruction scheduling * 1 vector iteration per 8 rounds */ - vmovdqu ((i * 2) + PRECALC_OFFSET)(BUFFER_PTR), W_TMP + vmovdqu (i * 2)(BUFFER_PTR), W_TMP .elseif ((i & 7) == 1) - vinsertf128 $1, (((i-1) * 2)+PRECALC_OFFSET)(BUFFER_PTR2),\ + vinsertf128 $1, ((i-1) * 2)(BUFFER_PTR2),\ WY_TMP, WY_TMP .elseif ((i & 7) == 2) vpshufb YMM_SHUFB_BSWAP, WY_TMP, WY .elseif ((i & 7) == 4) - vpaddd K_XMM(K_BASE), WY, WY_TMP + vpaddd K_XMM + K_XMM_AR(%rip), WY, WY_TMP .elseif ((i & 7) == 7) vmovdqu WY_TMP, PRECALC_WK(i&~7)
@@ -255,7 +254,7 @@ vpxor WY, WY_TMP, WY_TMP .elseif ((i & 7) == 7) vpxor WY_TMP2, WY_TMP, WY - vpaddd K_XMM(K_BASE), WY, WY_TMP + vpaddd K_XMM + K_XMM_AR(%rip), WY, WY_TMP vmovdqu WY_TMP, PRECALC_WK(i&~7) PRECALC_ROTATE_WY
@@ -291,7 +290,7 @@ vpsrld $30, WY, WY vpor WY, WY_TMP, WY .elseif ((i & 7) == 7) - vpaddd K_XMM(K_BASE), WY, WY_TMP + vpaddd K_XMM + K_XMM_AR(%rip), WY, WY_TMP vmovdqu WY_TMP, PRECALC_WK(i&~7) PRECALC_ROTATE_WY
@@ -446,6 +445,16 @@ .endm +/* Add constant only if (%2 > %3) condition met (uses RTA as temp) + * %1 + %2 >= %3 ? %4 : 0 + */ +.macro ADD_IF_GE a, b, c, d + mov \a, RTA + add $\d, RTA + cmp $\c, \b + cmovge RTA, \a +.endm + /* * macro implements 80 rounds of SHA-1, for multiple blocks with s/w pipelining */
@@ -463,13 +472,16 @@ lea (2*4*80+32)(%rsp), WK_BUF # Precalc WK for first 2 blocks - PRECALC_OFFSET = 0 + ADD_IF_GE BUFFER_PTR2, BLOCKS_CTR, 2, 64 .set i, 0 .rept 160 PRECALC i .set i, i + 1 .endr - PRECALC_OFFSET = 128 + + /* Go to next block if needed */ + ADD_IF_GE BUFFER_PTR, BLOCKS_CTR, 3, 128 + ADD_IF_GE BUFFER_PTR2, BLOCKS_CTR, 4, 128 xchg WK_BUF, PRECALC_BUF .align 32
@@ -479,8 +491,8 @@ _loop: * we use K_BASE value as a signal of a last block, * it is set below by: cmovae BUFFER_PTR, K_BASE */ - cmp K_BASE, BUFFER_PTR - jne _begin + test BLOCKS_CTR, BLOCKS_CTR + jnz _begin .align 32 jmp _end .align 32
@@ -512,10 +524,10 @@ _loop0: .set j, j+2 .endr - add $(2*64), BUFFER_PTR /* move to next odd-64-byte block */ - cmp BUFFER_END, BUFFER_PTR /* is current block the last one? */ - cmovae K_BASE, BUFFER_PTR /* signal the last iteration smartly */ - + /* Update Counter */ + sub $1, BLOCKS_CTR + /* Move to the next block only if needed*/ + ADD_IF_GE BUFFER_PTR, BLOCKS_CTR, 4, 128 /* * rounds * 60,62,64,66,68
@@ -532,8 +544,8 @@ _loop0: UPDATE_HASH 12(HASH_PTR), D UPDATE_HASH 16(HASH_PTR), E - cmp K_BASE, BUFFER_PTR /* is current block the last one? */ - je _loop + test BLOCKS_CTR, BLOCKS_CTR + jz _loop mov TB, B
@@ -575,10 +587,10 @@ _loop2: .set j, j+2 .endr - add $(2*64), BUFFER_PTR2 /* move to next even-64-byte block */ - - cmp BUFFER_END, BUFFER_PTR2 /* is current block the last one */ - cmovae K_BASE, BUFFER_PTR /* signal the last iteration smartly */ + /* update counter */ + sub $1, BLOCKS_CTR + /* Move to the next block only if needed*/ + ADD_IF_GE BUFFER_PTR2, BLOCKS_CTR, 4, 128 jmp _loop3 _loop3:
@@ -641,19 +653,12 @@ _loop3: avx2_zeroupper - lea K_XMM_AR(%rip), K_BASE - + /* Setup initial values */ mov CTX, HASH_PTR mov BUF, BUFFER_PTR - lea 64(BUF), BUFFER_PTR2 - - shl $6, CNT /* mul by 64 */ - add BUF, CNT - add $64, CNT - mov CNT, BUFFER_END - cmp BUFFER_END, BUFFER_PTR2 - cmovae K_BASE, BUFFER_PTR2 + mov BUF, BUFFER_PTR2 + mov CNT, BLOCKS_CTR xmm_mov BSWAP_SHUFB_CTL(%rip), YMM_SHUFB_BSWAP
arch/x86/crypto/sha1_ssse3_glue.c +1 -1
@@ -201,7 +201,7 @@ asmlinkage void sha1_transform_avx2(u32static bool avx2_usable (void ) { -if (false &&avx_usable () &&boot_cpu_has (X86_FEATURE_AVX2 ) +if (avx_usable () &&boot_cpu_has (X86_FEATURE_AVX2 ) &&boot_cpu_has (X86_FEATURE_BMI1 ) &&boot_cpu_has (X86_FEATURE_BMI2 ))return true;
Greg Kroah-Hartman
maintainerPATCH 6/27 Input: elan_i2c - add ELAN0608 to the ACPI table
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kai-Heng Feng <[email protected]>
commit 1874064eed0502bd9bef7be8023757b0c4f26883 upstream.
Similar to commit 722c5ac708b4f ("Input: elan_i2c - add ELAN0605 to the ACPI table"), ELAN0608 should be handled by elan_i2c.
This touchpad can be found in Lenovo ideapad 320-14IKB.
--- drivers/input/mouse/elan_i2c_core.c | 1 + 1 file changed, 1 insertion(+)
drivers/input/mouse/elan_i2c_core.c +1 -0
@@ -1235,6 +1235,7 @@ static const struct acpi_device_id elan_ { "ELAN0100", 0 }, { "ELAN0600", 0 }, { "ELAN0605", 0 }, + { "ELAN0608", 0 }, { "ELAN1000", 0 }, { } };
Greg Kroah-Hartman
maintainerPATCH 7/27 Input: elan_i2c - Add antoher Lenovo ACPI ID for upcoming Lenovo NB
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: KT Liao <[email protected]>
commit 76988690402dde2880bfe06ecccf381d48ba8e1c upstream.
Add 2 new IDs (ELAN0609 and ELAN060B) to the list of ACPI IDs that should be handled by the driver.
--- drivers/input/mouse/elan_i2c_core.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/input/mouse/elan_i2c_core.c +3 -0
@@ -1236,6 +1236,9 @@ static const struct acpi_device_id elan_ { "ELAN0600", 0 }, { "ELAN0605", 0 }, { "ELAN0608", 0 }, + { "ELAN0605", 0 }, + { "ELAN0609", 0 }, + { "ELAN060B", 0 }, { "ELAN1000", 0 }, { } };
Greg Kroah-Hartman
maintainerPATCH 8/27 ALSA: seq: 2nd attempt at fixing race creating a queue
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Mentz <[email protected]>
commit 7e1d90f60a0d501c8503e636942ca704a454d910 upstream.
commit 4842e98f26dd80be3623c4714a244ba52ea096a8 ("ALSA: seq: Fix race at creating a queue") attempted to fix a race reported by syzkaller. That fix has been described as follows:
"
When a sequencer queue is created in snd_seq_queue_alloc(),it adds the new queue element to the public list before referencing it. Thus the queue might be deleted before the call of snd_seq_queue_use(), and it results in the use-after-free error, as spotted by syzkaller.
The fix is to reference the queue object at the right time. "
Even with that fix in place, syzkaller reported a use-after-free error. It specifically pointed to the last instruction "return q->queue" in snd_seq_queue_alloc(). The pointer q is being used after kfree() has been called on it.
It turned out that there is still a small window where a race can happen. The window opens at snd_seq_ioctl_create_queue()->snd_seq_queue_alloc()->queue_list_add() and closes at snd_seq_ioctl_create_queue()->queueptr()->snd_use_lock_use(). Between these two calls, a different thread could delete the queue and possibly re-create a different queue in the same location in queue_list.
This change prevents this situation by calling snd_use_lock_use() from snd_seq_queue_alloc() prior to calling queue_list_add(). It is then the caller's responsibility to call snd_use_lock_free(&q->use_lock).
--- sound/core/seq/seq_clientmgr.c | 13 ++++--------- sound/core/seq/seq_queue.c | 14 +++++++++----- sound/core/seq/seq_queue.h | 2 +- 3 files changed, 14 insertions(+), 15 deletions(-)
sound/core/seq/seq_clientmgr.c +4 -9
@@ -1502,16 +1502,11 @@ static int snd_seq_ioctl_unsubscribe_porstatic int snd_seq_ioctl_create_queue (struct snd_seq_client *client,void *arg) {struct snd_seq_queue_info *info = arg; -int result;struct snd_seq_queue *q; - result =snd_seq_queue_alloc (client->number, info->locked, info->flags); -if (result <0 ) -return result; - - q =queueptr (result); -if (q ==NULL ) -return -EINVAL ; + q =snd_seq_queue_alloc (client->number, info->locked, info->flags); +if (IS_ERR (q)) +return PTR_ERR (q); info->queue = q->queue; info->locked = q->locked;
@@ -1521,7 +1516,7 @@ static int snd_seq_ioctl_create_queue(stif (!info->name[0 ])snprintf (info->name,sizeof (info->name),"Queue-%d" , q->queue);strlcpy (q->name, info->name,sizeof (q->name)); -queuefree (q); +snd_use_lock_free (&q->use_lock);return 0 ; }
sound/core/seq/seq_queue.c +9 -5
@@ -184,22 +184,26 @@ void __exit snd_seq_queues_delete(void)static void queue_use (struct snd_seq_queue *queue,int client,int use);/* allocate a new queue - -* return queue index value or negative value for error +* return pointer to new queue or ERR_PTR(-errno) for error +* The new queue's use_lock is set to 1. It is the caller's responsibility to +* call snd_use_lock_free(&q->use_lock). */ -int snd_seq_queue_alloc (int client,int locked,unsigned int info_flags) +struct snd_seq_queue *snd_seq_queue_alloc (int client,int locked,unsigned int info_flags) {struct snd_seq_queue *q; q =queue_new (client, locked);if (q ==NULL ) -return -ENOMEM ; +return ERR_PTR (-ENOMEM ); q->info_flags = info_flags;queue_use (q, client,1 ); +snd_use_lock_use (&q->use_lock);if (queue_list_add (q) <0 ) { +snd_use_lock_free (&q->use_lock);queue_delete (q); -return -ENOMEM ; +return ERR_PTR (-ENOMEM ); } -return q->queue; +return q; }/* delete a queue - queue must be owned by the client */
sound/core/seq/seq_queue.h +1 -1
@@ -71,7 +71,7 @@ void snd_seq_queues_delete(void);/* create new queue (constructor) */ -int snd_seq_queue_alloc (int client,int locked,unsigned int flags); +struct snd_seq_queue *snd_seq_queue_alloc (int client,int locked,unsigned int flags);/* delete queue (destructor) */ int snd_seq_queue_delete (int client,int queueid);
Greg Kroah-Hartman
maintainerPATCH 9/27 ALSA: usb-audio: Apply sample rate quirk to Sennheiser headset
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit a8e800fe0f68bc28ce309914f47e432742b865ed upstream.
A Senheisser headset requires the typical sample-rate quirk for avoiding spurious errors from inquiring the current sample rate like:
usb 1-1: 2:1: cannot get freq at ep 0x4
usb 1-1: 3:1: cannot get freq at ep 0x83
The USB ID 1395:740a has to be added to the entries in snd_usb_get_sample_rate_quirk().
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1052580
--- sound/usb/quirks.c | 1 + 1 file changed, 1 insertion(+)
sound/usb/quirks.c +1 -0
@@ -1142,6 +1142,7 @@ bool snd_usb_get_sample_rate_quirk(struccase USB_ID (0x0556 ,0x0014 ):/* Phoenix Audio TMX320VC */ case USB_ID (0x05A3 ,0x9420 ):/* ELP HD USB Camera */ case USB_ID (0x074D ,0x3553 ):/* Outlaw RR2150 (Micronas UAC3553B) */ +case USB_ID (0x1395 ,0x740a ):/* Sennheiser DECT */ case USB_ID (0x1901 ,0x0191 ):/* GE B850V3 CP2114 audio interface */ case USB_ID (0x1de7 ,0x0013 ):/* Phoenix Audio MT202exe */ case USB_ID (0x1de7 ,0x0014 ):/* Phoenix Audio TMX320 */
Greg Kroah-Hartman
maintainerPATCH 10/27 ALSA: usb-audio: Add mute TLV for playback volumes on C-Media devices
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 0f174b3525a43bd51f9397394763925e0ebe7bc7 upstream.
C-Media devices (at least some models) mute the playback stream when volumes are set to the minimum value. But this isn't informed via TLV and the user-space, typically PulseAudio, gets confused as if it's still played in a low volume.
This patch adds the new flag, min_mute, to struct usb_mixer_elem_info for indicating that the mixer element is with the minimum-mute volume. This flag is set for known C-Media devices in snd_usb_mixer_fu_apply_quirk() in turn.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196669
--- sound/usb/mixer.c | 2 ++ sound/usb/mixer.h | 1 + sound/usb/mixer_quirks.c | 6 ++++++ 3 files changed, 9 insertions(+)
sound/usb/mixer.c +2 -0
@@ -542,6 +542,8 @@ int snd_usb_mixer_vol_tlv(struct snd_kcoif (size <sizeof (scale))return -ENOMEM ; +if (cval->min_mute) + scale[0 ] =SNDRV_CTL_TLVT_DB_MINMAX_MUTE ; scale[2 ] = cval->dBmin; scale[3 ] = cval->dBmax;if (copy_to_user (_tlv, scale,sizeof (scale)))
sound/usb/mixer.h +1 -0
@@ -64,6 +64,7 @@ struct usb_mixer_elem_info {int cached;int cache_val[MAX_CHANNELS ];u8 initialized; +u8 min_mute;void *private_data; };
sound/usb/mixer_quirks.c +6 -0
@@ -1873,6 +1873,12 @@ void snd_usb_mixer_fu_apply_quirk(structif (unitid ==7 && cval->control ==UAC_FU_VOLUME )snd_dragonfly_quirk_db_scale (mixer, cval, kctl);break ; +/* lowest playback value is muted on C-Media devices */ +case USB_ID (0x0d8c ,0x000c ): +case USB_ID (0x0d8c ,0x0014 ): +if (strstr (kctl->id.name,"Playback" )) + cval->min_mute =1 ; +break ; } }
Greg Kroah-Hartman
maintainerPATCH 11/27 mm: discard memblock data later
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Tatashin <[email protected]>
commit 3010f876500f9ba921afaeccec30c45ca6584dc8 upstream.
There is existing use after free bug when deferred struct pages are enabled:
The memblock_add() allocates memory for the memory array if more than 128 entries are needed. See comment in e820__memblock_setup():
* The bootstrap memblock region count maximum is 128 entries
* (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries
* than that - so allow memblock resizing.
This memblock memory is freed here:
free_low_memory_core_early()
We access the freed memblock.memory later in boot when deferred pages are initialized in this path:
deferred_init_memmap()
for_each_mem_pfn_range()
__next_mem_pfn_range()
type = &memblock.memory;One possible explanation for why this use-after-free hasn't been hit before is that the limit of INIT_MEMBLOCK_REGIONS has never been exceeded at least on systems where deferred struct pages were enabled.
Tested by reducing INIT_MEMBLOCK_REGIONS down to 4 from the current 128, and verifying in qemu that this code is getting excuted and that the freed pages are sane.
--- include/linux/memblock.h | 6 ++++-- mm/memblock.c | 40 ++++++++++++++++++---------------------- mm/nobootmem.c | 16 ---------------- mm/page_alloc.c | 4 ++++ 4 files changed, 26 insertions(+), 40 deletions(-)
include/linux/memblock.h +4 -2
@@ -64,6 +64,7 @@ extern bool movable_node_enabled;#ifdef CONFIG_ARCH_DISCARD_MEMBLOCK #define __init_memblock __meminit#define __initdata_memblock __meminitdata +void memblock_discard (void );#else #define __init_memblock#define __initdata_memblock
@@ -77,8 +78,6 @@ phys_addr_t memblock_find_in_range_node( int nid, ulong flags);phys_addr_t memblock_find_in_range (phys_addr_t start,phys_addr_t end,phys_addr_t size,phys_addr_t align); -phys_addr_t get_allocated_memblock_reserved_regions_info (phys_addr_t *addr); -phys_addr_t get_allocated_memblock_memory_regions_info (phys_addr_t *addr);void memblock_allow_resize (void );int memblock_add_node (phys_addr_t base,phys_addr_t size,int nid);int memblock_add (phys_addr_t base,phys_addr_t size);
@@ -112,6 +111,9 @@ void __next_mem_range_rev(u64 *idx, intvoid __next_reserved_mem_region (u64 *idx,phys_addr_t *out_start,phys_addr_t *out_end); +void __memblock_free_early (phys_addr_t base,phys_addr_t size); +void __memblock_free_late (phys_addr_t base,phys_addr_t size); +/** * for_each_mem_range - iterate through memblock areas from type_a and not * included in type_b. Or just type_a if type_b is NULL.
mm/memblock.c +18 -22
@@ -297,31 +297,27 @@ static void __init_memblock memblock_rem }#ifdef CONFIG_ARCH_DISCARD_MEMBLOCK - -phys_addr_t __init_memblock get_allocated_memblock_reserved_regions_info( -phys_addr_t *addr) -{ -if (memblock.reserved.regions == memblock_reserved_init_regions) -return 0 ; - - *addr =__pa (memblock.reserved.regions); - -return PAGE_ALIGN (sizeof (struct memblock_region ) * - memblock.reserved.max); -} - -phys_addr_t __init_memblock get_allocated_memblock_memory_regions_info( -phys_addr_t *addr) +/** +* Discard memory and reserved arrays if they were allocated +*/ +void __init memblock_discard (void ) { -if (memblock.memory.regions == memblock_memory_init_regions) -return 0 ; +phys_addr_t addr, size; - *addr =__pa (memblock.memory.regions); - -return PAGE_ALIGN (sizeof (struct memblock_region ) * - memblock.memory.max); +if (memblock.reserved.regions != memblock_reserved_init_regions) { + addr =__pa (memblock.reserved.regions); + size =PAGE_ALIGN (sizeof (struct memblock_region ) * + memblock.reserved.max); +__memblock_free_late (addr, size); + } + +if (memblock.memory.regions == memblock_memory_init_regions) { + addr =__pa (memblock.memory.regions); + size =PAGE_ALIGN (sizeof (struct memblock_region ) * + memblock.memory.max); +__memblock_free_late (addr, size); + } } -#endif /**
mm/nobootmem.c +0 -16
@@ -146,22 +146,6 @@ static unsigned long __init free_low_mem NULL) count +=__free_memory_core (start, end); -#ifdef CONFIG_ARCH_DISCARD_MEMBLOCK - { -phys_addr_t size; - -/* Free memblock.reserved array if it was allocated */ - size =get_allocated_memblock_reserved_regions_info (&start); -if (size) - count +=__free_memory_core (start, start + size); - -/* Free memblock.memory array if it was allocated */ - size =get_allocated_memblock_memory_regions_info (&start); -if (size) - count +=__free_memory_core (start, start + size); - } -#endif -return count; }
mm/page_alloc.c +4 -0
@@ -1587,6 +1587,10 @@ void __init page_alloc_init_late(void)/* Reinit limits that are based on free pages after the kernel is up */ files_maxfiles_init ();#endif +#ifdef CONFIG_ARCH_DISCARD_MEMBLOCK +/* Discard memblock private memory */ +memblock_discard (); +#endif for_each_populated_zone (zone)set_zone_contiguous (zone);
Greg Kroah-Hartman
maintainerPATCH 12/27 mm: fix double mmap_sem unlock on MMF_UNSTABLE enforced SIGBUS
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Hocko <[email protected]>
commit 5b53a6ea886700a128b697a6fe8375340dea2c30 upstream.
Tetsuo Handa has noticed that MMF_UNSTABLE SIGBUS path in handle_mm_fault causes a lockdep splat
Out of memory: Kill process 1056 (a.out) score 603 or sacrifice child
Killed process 1056 (a.out) total-vm:4268108kB, anon-rss:2246048kB, file-rss:0kB, shmem-rss:0kB a.out (1169) used greatest stack depth: 11664 bytes left DEBUG_LOCKS_WARN_ON(depth <= 0)
------------[ cut here ]------------
WARNING: CPU: 6 PID: 1339 at kernel/locking/lockdep.c:3617 lock_release+0x172/0x1e0
CPU: 6 PID: 1339 Comm: a.out Not tainted 4.13.0-rc3-next-20170803+ #142
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
RIP: 0010:lock_release+0x172/0x1e0
Call Trace:
up_read+0x1a/0x40
__do_page_fault+0x28e/0x4c0
do_page_fault+0x30/0x80
page_fault+0x28/0x30The reason is that the page fault path might have dropped the mmap_sem and returned with VM_FAULT_RETRY. MMF_UNSTABLE check however rewrites the error path to VM_FAULT_SIGBUS and we always expect mmap_sem taken in that path. Fix this by taking mmap_sem when VM_FAULT_RETRY is held in the MMF_UNSTABLE path.
We cannot simply add VM_FAULT_SIGBUS to the existing error code because all arch specific page fault handlers and g-u-p would have to learn a new error code combination.
--- mm/memory.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
mm/memory.c +11 -1
@@ -3635,8 +3635,18 @@ int handle_mm_fault(struct vm_area_struc* further. */ if (unlikely ((current->flags &PF_KTHREAD ) && !(ret &VM_FAULT_ERROR ) - &&test_bit (MMF_UNSTABLE , &vma->vm_mm->flags))) + &&test_bit (MMF_UNSTABLE , &vma->vm_mm->flags))) { + +/* +* We are going to enforce SIGBUS but the PF path might have +* dropped the mmap_sem already so take it again so that +* we do not break expectations of all arch specific PF paths +* and g-u-p +*/ +if (ret &VM_FAULT_RETRY ) +down_read (&vma->vm_mm->mmap_sem); ret =VM_FAULT_SIGBUS ; + }return ret; }
Greg Kroah-Hartman
maintainerPATCH 13/27 mm/mempolicy: fix use after free when calling get_mempolicy
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: zhong jiang <[email protected]>
commit 73223e4e2e3867ebf033a5a8eb2e5df0158ccc99 upstream.
I hit a use after free issue when executing trinity and repoduced it with KASAN enabled. The related call trace is as follows.
BUG: KASan: use after free in SyS_get_mempolicy+0x3c8/0x960 at addr ffff8801f582d766 Read of size 2 by task syz-executor1/798
INFO: Allocated in mpol_new.part.2+0x74/0x160 age=3 cpu=1 pid=799
__slab_alloc+0x768/0x970
kmem_cache_alloc+0x2e7/0x450
mpol_new.part.2+0x74/0x160
mpol_new+0x66/0x80
SyS_mbind+0x267/0x9f0
system_call_fastpath+0x16/0x1b
INFO: Freed in __mpol_put+0x2b/0x40 age=4 cpu=1 pid=799
__slab_free+0x495/0x8e0
kmem_cache_free+0x2f3/0x4c0
__mpol_put+0x2b/0x40
SyS_mbind+0x383/0x9f0
system_call_fastpath+0x16/0x1b
INFO: Slab 0xffffea0009cb8dc0 objects=23 used=8 fp=0xffff8801f582de40 flags=0x200000000004080
INFO: Object 0xffff8801f582d760 @offset=5984 fp=0xffff8801f582d600 Bytes b4 ffff8801f582d750: ae 01 ff ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ Object ffff8801f582d760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8801f582d770: 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkk.
Redzone ffff8801f582d778: bb bb bb bb bb bb bb bb ........
Padding ffff8801f582d8b8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
Memory state around the buggy address: ffff8801f582d600: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8801f582d680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff8801f582d700: fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb fc
!shared memory policy is not protected against parallel removal by other thread which is normally protected by the mmap_sem. do_get_mempolicy, however, drops the lock midway while we can still access it later.
Early premature up_read is a historical artifact from times when put_user was called in this path see https://lwn.net/Articles/124754/
but that is gone since 8bccd85ffbaf ("[PATCH] Implement sys_* do_* layering in the memory policy layer."). but when we have the the current mempolicy ref count model. The issue was introduced accordingly.
Fix the issue by removing the premature release.
--- mm/mempolicy.c | 5 ----- 1 file changed, 5 deletions(-)
mm/mempolicy.c +0 -5
@@ -926,11 +926,6 @@ static long do_get_mempolicy(int *policy *policy |= (pol->flags &MPOL_MODE_FLAGS ); } -if (vma) { -up_read (¤t->mm->mmap_sem); - vma =NULL ; - } - err =0 ;if (nmask) {if (mpol_store_user_nodemask (pol)) {
Greg Kroah-Hartman
maintainerPATCH 14/27 mm: revert x86_64 and arm64 ELF_ET_DYN_BASE base changes
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <[email protected]>
commit c715b72c1ba406f133217b509044c38d8e714a37 upstream.
Moving the x86_64 and arm64 PIE base from 0x555555554000 to 0x000100000000 broke AddressSanitizer. This is a partial revert of:
eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE") 02445990a96e ("arm64: move ELF_ET_DYN_BASE to 4GB / 4MB")
The AddressSanitizer tool has hard-coded expectations about where executable mappings are loaded.
The motivation for changing the PIE base in the above commits was to avoid the Stack-Clash CVEs that allowed executable mappings to get too close to heap and stack. This was mainly a problem on 32-bit, but the 64-bit bases were moved too, in an effort to proactively protect those systems (proofs of concept do exist that show 64-bit collisions, but other recent changes to fix stack accounting and setuid behaviors will minimize the impact).
The new 32-bit PIE base is fine for ASan (since it matches the ET_EXEC base), so only the 64-bit PIE base needs to be reverted to let x86 and arm64 ASan binaries run again. Future changes to the 64-bit PIE base on these architectures can be made optional once a more dynamic method for dealing with AddressSanitizer is found. (e.g. always loading PIE into the mmap region for marked binaries.)
--- arch/arm64/include/asm/elf.h | 4 ++-- arch/x86/include/asm/elf.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
arch/arm64/include/asm/elf.h +2 -2
@@ -114,10 +114,10 @@/* * This is the base location for PIE (ET_DYN with INTERP) loads. On -* 64-bit, this is raised to 4GB to leave the entire 32-bit address +* 64-bit, this is above 4GB to leave the entire 32-bit address * space open for things that want to use the area for 32-bit pointers. */ -#define ELF_ET_DYN_BASE 0x100000000UL +#define ELF_ET_DYN_BASE (2 * TASK_SIZE_64 / 3)#ifndef __ASSEMBLY__
arch/x86/include/asm/elf.h +2 -2
@@ -247,11 +247,11 @@ extern int force_personality32;/* * This is the base location for PIE (ET_DYN with INTERP) loads. On -* 64-bit, this is raised to 4GB to leave the entire 32-bit address +* 64-bit, this is above 4GB to leave the entire 32-bit address * space open for things that want to use the area for 32-bit pointers. */ #define ELF_ET_DYN_BASE (mmap_is_ia32() ? 0x000400000UL : \ - 0x100000000UL) + (TASK_SIZE / 3 * 2))/* This yields a mask that user programs can use to figure out what instruction set this CPU supports. This could be done in user space,
Greg Kroah-Hartman
maintainerPATCH 16/27 blk-mq-pci: add a fallback when pci_irq_get_affinity returns NULL
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoph Hellwig <[email protected]>
commit c005390374957baacbc38eef96ea360559510aa7 upstream.
While pci_irq_get_affinity should never fail for SMP kernel that implement the affinity mapping, it will always return NULL in the UP case, so provide a fallback mapping of all queues to CPU 0 in that case.
--- block/blk-mq-pci.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
block/blk-mq-pci.c +7 -1
@@ -36,12 +36,18 @@ int blk_mq_pci_map_queues(struct blk_mq_for (queue =0 ; queue < set->nr_hw_queues; queue++) { mask =pci_irq_get_affinity (pdev, queue);if (!mask) -return -EINVAL ; + goto fallback;for_each_cpu (cpu, mask) set->mq_map[cpu] = queue; }return 0 ; + +fallback: +WARN_ON_ONCE (set->nr_hw_queues >1 ); +for_each_possible_cpu (cpu) + set->mq_map[cpu] =0 ; +return 0 ; }EXPORT_SYMBOL_GPL (blk_mq_pci_map_queues);
Greg Kroah-Hartman
maintainerPATCH 17/27 powerpc: Fix VSX enabling/flushing to also test MSR_FP and MSR_VEC
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Benjamin Herrenschmidt <[email protected]>
commit 5a69aec945d27e78abac9fd032533d3aaebf7c1e upstream.
VSX uses a combination of the old vector registers, the old FP registers and new "second halves" of the FP registers.
Thus when we need to see the VSX state in the thread struct (flush_vsx_to_thread()) or when we'll use the VSX in the kernel (enable_kernel_vsx()) we need to ensure they are all flushed into the thread struct if either of them is individually enabled.
Unfortunately we only tested if the whole VSX was enabled, not if they were individually enabled.
--- arch/powerpc/kernel/process.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
arch/powerpc/kernel/process.c +3 -2
@@ -359,7 +359,8 @@ void enable_kernel_vsx(void) cpumsr =msr_check_and_set (MSR_FP |MSR_VEC |MSR_VSX ); -if (current->thread.regs && (current->thread.regs->msr &MSR_VSX )) { +if (current->thread.regs && + (current->thread.regs->msr & (MSR_VSX |MSR_VEC |MSR_FP ))) {check_if_tm_restore_required (current);/* * If a thread has already been reclaimed then the
@@ -383,7 +384,7 @@ void flush_vsx_to_thread(struct task_str {if (tsk->thread.regs) {preempt_disable (); -if (tsk->thread.regs->msr &MSR_VSX ) { +if (tsk->thread.regs->msr & (MSR_VSX |MSR_VEC |MSR_FP )) {BUG_ON (tsk != current);giveup_vsx (tsk); }
Greg Kroah-Hartman
maintainerPATCH 18/27 xen-blkfront: use a right index when checking requests
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Munehisa Kamata <[email protected]>
commit b15bd8cb37598afb2963f7eb9e2de468d2d60a2f upstream.
Since commit d05d7f40791c ("Merge branch 'for-4.8/core' ofgit://git.kernel.dk/linux-block") and 3fc9d690936f ("Merge branch 'for-4.8/drivers' of git://git.kernel.dk/linux-block"), blkfront_resume() has been using an index for iterating ring_info to check request when iterating blk_shadow in an inner loop. This seems to have been accidentally introduced during the massive rewrite of the block layer macros in the commits.
This may cause crash like this:
[11798.057074] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 [11798.058832] IP: [<ffffffff814411fa>] blkfront_resume+0x10a/0x610 .... [11798.061063] Call Trace: [11798.061063] [<ffffffff8139ce93>] xenbus_dev_resume+0x53/0x140 [11798.061063] [<ffffffff8139ce40>] ? xenbus_dev_probe+0x150/0x150 [11798.061063] [<ffffffff813f359e>] dpm_run_callback+0x3e/0x110 [11798.061063] [<ffffffff813f3a08>] device_resume+0x88/0x190 [11798.061063] [<ffffffff813f4cc0>] dpm_resume+0x100/0x2d0 [11798.061063] [<ffffffff813f5221>] dpm_resume_end+0x11/0x20 [11798.061063] [<ffffffff813950a8>] do_suspend+0xe8/0x1a0 [11798.061063] [<ffffffff813954bd>] shutdown_handler+0xfd/0x130 [11798.061063] [<ffffffff8139aba0>] ? split+0x110/0x110 [11798.061063] [<ffffffff8139ac26>] xenwatch_thread+0x86/0x120 [11798.061063] [<ffffffff810b4570>] ? prepare_to_wait_event+0x110/0x110 [11798.061063] [<ffffffff8108fe57>] kthread+0xd7/0xf0 [11798.061063] [<ffffffff811da811>] ? kfree+0x121/0x170 [11798.061063] [<ffffffff8108fd80>] ? kthread_park+0x60/0x60 [11798.061063] [<ffffffff810863b0>] ? call_usermodehelper_exec_work+0xb0/0xb0 [11798.061063] [<ffffffff810864ea>] ? call_usermodehelper_exec_async+0x13a/0x140 [11798.061063] [<ffffffff81534a45>] ret_from_fork+0x25/0x30
Use the right index in the inner loop.
--- drivers/block/xen-blkfront.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/block/xen-blkfront.c +3 -3
@@ -2112,9 +2112,9 @@ static int blkfront_resume(struct xenbus/* * Get the bios in the request so we can re-queue them. */ -if (req_op (shadow[i].request) ==REQ_OP_FLUSH || -req_op (shadow[i].request) ==REQ_OP_DISCARD || -req_op (shadow[i].request) ==REQ_OP_SECURE_ERASE || +if (req_op (shadow[j].request) ==REQ_OP_FLUSH || +req_op (shadow[j].request) ==REQ_OP_DISCARD || +req_op (shadow[j].request) ==REQ_OP_SECURE_ERASE || shadow[j].request->cmd_flags &REQ_FUA ) {/* * Flush operations don't contain bios, so
Greg Kroah-Hartman
maintainerPATCH 18/27 xen-blkfront: use a right index when checking requests
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Munehisa Kamata <[email protected]>
commit b15bd8cb37598afb2963f7eb9e2de468d2d60a2f upstream.
Since commit d05d7f40791c ("Merge branch 'for-4.8/core' ofgit://git.kernel.dk/linux-block") and 3fc9d690936f ("Merge branch 'for-4.8/drivers' of git://git.kernel.dk/linux-block"), blkfront_resume() has been using an index for iterating ring_info to check request when iterating blk_shadow in an inner loop. This seems to have been accidentally introduced during the massive rewrite of the block layer macros in the commits.
This may cause crash like this:
[11798.057074] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 [11798.058832] IP: [<ffffffff814411fa>] blkfront_resume+0x10a/0x610 .... [11798.061063] Call Trace: [11798.061063] [<ffffffff8139ce93>] xenbus_dev_resume+0x53/0x140 [11798.061063] [<ffffffff8139ce40>] ? xenbus_dev_probe+0x150/0x150 [11798.061063] [<ffffffff813f359e>] dpm_run_callback+0x3e/0x110 [11798.061063] [<ffffffff813f3a08>] device_resume+0x88/0x190 [11798.061063] [<ffffffff813f4cc0>] dpm_resume+0x100/0x2d0 [11798.061063] [<ffffffff813f5221>] dpm_resume_end+0x11/0x20 [11798.061063] [<ffffffff813950a8>] do_suspend+0xe8/0x1a0 [11798.061063] [<ffffffff813954bd>] shutdown_handler+0xfd/0x130 [11798.061063] [<ffffffff8139aba0>] ? split+0x110/0x110 [11798.061063] [<ffffffff8139ac26>] xenwatch_thread+0x86/0x120 [11798.061063] [<ffffffff810b4570>] ? prepare_to_wait_event+0x110/0x110 [11798.061063] [<ffffffff8108fe57>] kthread+0xd7/0xf0 [11798.061063] [<ffffffff811da811>] ? kfree+0x121/0x170 [11798.061063] [<ffffffff8108fd80>] ? kthread_park+0x60/0x60 [11798.061063] [<ffffffff810863b0>] ? call_usermodehelper_exec_work+0xb0/0xb0 [11798.061063] [<ffffffff810864ea>] ? call_usermodehelper_exec_async+0x13a/0x140 [11798.061063] [<ffffffff81534a45>] ret_from_fork+0x25/0x30
Use the right index in the inner loop.
--- drivers/block/xen-blkfront.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/block/xen-blkfront.c +3 -3
@@ -2112,9 +2112,9 @@ static int blkfront_resume(struct xenbus/* * Get the bios in the request so we can re-queue them. */ -if (req_op (shadow[i].request) ==REQ_OP_FLUSH || -req_op (shadow[i].request) ==REQ_OP_DISCARD || -req_op (shadow[i].request) ==REQ_OP_SECURE_ERASE || +if (req_op (shadow[j].request) ==REQ_OP_FLUSH || +req_op (shadow[j].request) ==REQ_OP_DISCARD || +req_op (shadow[j].request) ==REQ_OP_SECURE_ERASE || shadow[j].request->cmd_flags &REQ_FUA ) {/* * Flush operations don't contain bios, so
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Greg Kroah-Hartman
maintainerPATCH 19/27 x86/asm/64: Clear AC on NMI entries
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <[email protected]>
commit e93c17301ac55321fc18e0f8316e924e58a83c8c upstream.
This closes a hole in our SMAP implementation.
This patch comes from grsecurity. Good catch!
--- arch/x86/entry/entry_64.S | 2 ++ 1 file changed, 2 insertions(+)
arch/x86/entry/entry_64.S +2 -0
@@ -1215,6 +1215,8 @@ ENTRY(nmi) * other IST entries. */ + ASM_CLAC + /* Use %rdx as our temp variable throughout */ pushq %rdx
Greg Kroah-Hartman
maintainerPATCH 20/27 irqchip/atmel-aic: Fix unbalanced of_node_put() in aic_common_irq_fixup()
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Brezillon <[email protected]>
commit 469bcef53c546bb792aa66303933272991b7831d upstream.
aic_common_irq_fixup() is calling twice of_node_put() on the same node thus leading to an unbalanced refcount on the root node.
--- drivers/irqchip/irq-atmel-aic-common.c | 1 - 1 file changed, 1 deletion(-)
drivers/irqchip/irq-atmel-aic-common.c +0 -1
@@ -196,7 +196,6 @@ static void __init aic_common_irq_fixup(return ; match =of_match_node (matches, root); -of_node_put (root);if (match) {void (*fixup)(struct device_node *) = match->data;
Greg Kroah-Hartman
maintainerPATCH 21/27 irqchip/atmel-aic: Fix unbalanced refcount in aic_common_rtc_irq_fixup()
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Brezillon <[email protected]>
commit 277867ade8262583f4280cadbe90e0031a3706a7 upstream.
of_find_compatible_node() is calling of_node_put() on its first argument thus leading to an unbalanced of_node_get/put() issue if the node has not been retained before that.
Instead of passing the root node, pass NULL, which does exactly the same:
iterate over all DT nodes, starting from the root node.
--- drivers/irqchip/irq-atmel-aic-common.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/irqchip/irq-atmel-aic-common.c +2 -2
@@ -142,9 +142,9 @@ void __init aic_common_rtc_irq_fixup(strstruct device_node *np;void __iomem *regs; - np =of_find_compatible_node (root,NULL ,"atmel,at91rm9200-rtc" ); + np =of_find_compatible_node (NULL ,NULL ,"atmel,at91rm9200-rtc" );if (!np) - np =of_find_compatible_node (root,NULL , + np =of_find_compatible_node (NULL ,NULL ,"atmel,at91sam9x5-rtc" );if (!np)
Greg Kroah-Hartman
maintainerPATCH 22/27 genirq: Restore trigger settings in irq_modify_status()
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <[email protected]>
commit e8f241893dfbbebe2813c01eac54f263e6a5e59c upstream.
irq_modify_status starts by clearing the trigger settings from irq_data before applying the new settings, but doesn't restore them, leaving them to IRQ_TYPE_NONE.
That's pretty confusing to the potential request_irq() that could follow. Instead, snapshot the settings before clearing them, and restore them if the irq_modify_status() invocation was not changing the trigger.
--- kernel/irq/chip.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
kernel/irq/chip.c +8 -2
@@ -895,13 +895,15 @@ EXPORT_SYMBOL_GPL(irq_set_chip_and_handlvoid irq_modify_status (unsigned int irq,unsigned long clr,unsigned long set) { -unsigned long flags; +unsigned long flags, trigger, tmp;struct irq_desc *desc =irq_get_desc_lock (irq, &flags,0 );if (!desc)return ;irq_settings_clr_and_set (desc, clr, set); + trigger =irqd_get_trigger_type (&desc->irq_data); +irqd_clear (&desc->irq_data,IRQD_NO_BALANCING |IRQD_PER_CPU |IRQD_TRIGGER_MASK |IRQD_LEVEL |IRQD_MOVE_PCNTXT );if (irq_settings_has_no_balance_set (desc))
@@ -913,7 +915,11 @@ void irq_modify_status(unsigned int irq,if (irq_settings_is_level (desc))irqd_set (&desc->irq_data,IRQD_LEVEL ); -irqd_set (&desc->irq_data,irq_settings_get_trigger_mask (desc)); + tmp =irq_settings_get_trigger_mask (desc); +if (tmp !=IRQ_TYPE_NONE ) + trigger = tmp; + +irqd_set (&desc->irq_data, trigger);irq_put_desc_unlock (desc, flags); }
Greg Kroah-Hartman
maintainerPATCH 23/27 genirq/ipi: Fixup checks against nr_cpu_ids
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexey Dobriyan <[email protected]>
commit 8fbbe2d7cc478d1544f41f2271787c993c23a4f6 upstream.
Valid CPU ids are [0, nr_cpu_ids-1] inclusive.
--- kernel/irq/ipi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/irq/ipi.c +2 -2
@@ -165,7 +165,7 @@ irq_hw_number_t ipi_get_hwirq(unsigned istruct irq_data *data =irq_get_irq_data (irq);struct cpumask *ipimask = data ?irq_data_get_affinity_mask (data) :NULL ; -if (!data || !ipimask || cpu > nr_cpu_ids) +if (!data || !ipimask || cpu >= nr_cpu_ids)return INVALID_HWIRQ ;if (!cpumask_test_cpu (cpu, ipimask))
@@ -195,7 +195,7 @@ static int ipi_send_verify(struct irq_chif (!chip->ipi_send_single && !chip->ipi_send_mask)return -EINVAL ; -if (cpu > nr_cpu_ids) +if (cpu >= nr_cpu_ids)return -EINVAL ;if (dest) {
Greg Kroah-Hartman
maintainerPATCH 24/27 Sanitize move_pages() permission checks
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Torvalds <[email protected]>
commit 197e7e521384a23b9e585178f3f11c9fa08274b9 upstream.
The 'move_paghes()' system call was introduced long long ago with the same permission checks as for sending a signal (except using CAP_SYS_NICE instead of CAP_SYS_KILL for the overriding capability).
That turns out to not be a great choice - while the system call really only moves physical page allocations around (and you need other capabilities to do a lot of it), you can check the return value to map out some the virtual address choices and defeat ASLR of a binary that still shares your uid.
So change the access checks to the more common 'ptrace_may_access()' model instead.
This tightens the access checks for the uid, and also effectively changes the CAP_SYS_NICE check to CAP_SYS_PTRACE, but it's unlikely that anybody really _uses_ this legacy system call any more (we hav ebetter NUMA placement models these days), so I expect nobody to notice.
Famous last words.
--- mm/migrate.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-)
mm/migrate.c +4 -9
@@ -40,6 +40,7 @@#include <linux/mmu_notifier.h> #include <linux/page_idle.h> #include <linux/page_owner.h> +#include <linux/ptrace.h> #include <asm/tlbflush.h>
@@ -1663,7 +1664,6 @@ SYSCALL_DEFINE6(move_pages, pid_t, pid, const int __user *, nodes, int __user *, status, int, flags) { - const struct cred *cred = current_cred(), *tcred; struct task_struct *task;struct mm_struct *mm;int err;
@@ -1687,14 +1687,9 @@ SYSCALL_DEFINE6(move_pages, pid_t, pid,/* * Check if this process has the right to modify the specified -* process. The right exists if the process has administrative -* capabilities, superuser privileges or the same -* userid as the target process. -*/ - tcred =__task_cred (task); -if (!uid_eq (cred->euid, tcred->suid) && !uid_eq (cred->euid, tcred->uid) && - !uid_eq (cred->uid, tcred->suid) && !uid_eq (cred->uid, tcred->uid) && - !capable (CAP_SYS_NICE )) { +* process. Use the regular "ptrace_may_access()" checks. +*/ +if (!ptrace_may_access (task,PTRACE_MODE_READ_REALCREDS )) {rcu_read_unlock (); err = -EPERM ; goto out;
Greg Kroah-Hartman
maintainerPATCH 25/27 pids: make task_tgid_nr_ns() safe
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oleg Nesterov <[email protected]>
commit dd1c1f2f2028a7b851f701fc6a8ebe39dcb95e7c upstream.
This was reported many times, and this was even mentioned in commit 52ee2dfdd4f5 ("pids: refactor vnr/nr_ns helpers to make them safe") but somehow nobody bothered to fix the obvious problem: task_tgid_nr_ns() is not safe because task->group_leader points to nowhere after the exiting task passes exit_notify(), rcu_read_lock() can not help.
We really need to change __unhash_process() to nullify group_leader, parent, and real_parent, but this needs some cleanups. Until then we can turn task_tgid_nr_ns() into another user of __task_pid_nr_ns() and fix the problem.
--- include/linux/pid.h | 4 +++- include/linux/sched.h | 50 +++++++++++++++++++++++++++----------------------- kernel/pid.c | 11 ++++------- 3 files changed, 34 insertions(+), 31 deletions(-)
include/linux/pid.h +3 -1
@@ -8,7 +8,9 @@ enum pid_typePIDTYPE_PID ,PIDTYPE_PGID ,PIDTYPE_SID , - PIDTYPE_MAX +PIDTYPE_MAX , +/* only valid to __task_pid_nr_ns() */ + __PIDTYPE_TGID };/*
include/linux/sched.h +27 -23
64 lines not on this page · raw message
kernel/pid.c +4 -7
@@ -526,8 +526,11 @@ pid_t __task_pid_nr_ns(struct task_strucif (!ns) ns =task_active_pid_ns (current);if (likely (pid_alive (task))) { -if (type !=PIDTYPE_PID ) +if (type !=PIDTYPE_PID ) { +if (type == __PIDTYPE_TGID) + type =PIDTYPE_PID ; task = task->group_leader; + } nr =pid_nr_ns (rcu_dereference (task->pids[type].pid), ns); }rcu_read_unlock ();
@@ -536,12 +539,6 @@ pid_t __task_pid_nr_ns(struct task_struc }EXPORT_SYMBOL (__task_pid_nr_ns); -pid_t task_tgid_nr_ns (struct task_struct *tsk,struct pid_namespace *ns) -{ -return pid_nr_ns (task_tgid (tsk), ns); -} -EXPORT_SYMBOL (task_tgid_nr_ns); -struct pid_namespace *task_active_pid_ns (struct task_struct *tsk) {return ns_of_pid (task_pid (tsk));
Greg Kroah-Hartman
maintainerPATCH 26/27 usb: optimize acpi companion search for usb port devices
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mathias Nyman <[email protected]>
commit ed18c5fa945768a9bec994e786edbbbc7695acf6 upstream.
This optimization significantly reduces xhci driver load time.
In ACPI tables the acpi companion port devices are children of the hub device. The port devices are identified by their port number returned by the ACPI _ADR method._ADR 0 is reserved for the root hub device.
The current implementation to find a acpi companion port device loops through all acpi port devices under that parent hub, evaluating their _ADR method each time a new port device is added.
for a xHC controller with 25 ports under its roothub it will end up invoking ACPI bytecode 625 times before all ports are ready, making it really slow.
The _ADR values are already read and cached earler. So instead of running the bytecode again we can check the cached _ADR value first, and then fall back to the old way.
As one of the more significant changes, the xhci load time on Intel kabylake reduced by 70%, (28ms) from
initcall xhci_pci_init+0x0/0x49 returned 0 after 39537 usecs to
initcall xhci_pci_init+0x0/0x49 returned 0 after 11270 usecs
--- drivers/usb/core/usb-acpi.c | 26 +++++++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-)
drivers/usb/core/usb-acpi.c +23 -3
@@ -127,6 +127,22 @@ out:*/ #define USB_ACPI_LOCATION_VALID (1 << 31) +static struct acpi_device *usb_acpi_find_port (struct acpi_device *parent, +int raw) +{ +struct acpi_device *adev; + +if (!parent) +return NULL ; + +list_for_each_entry (adev, &parent->children, node) { +if (acpi_device_adr (adev) == raw) +return adev; + } + +return acpi_find_child_device (parent, raw, false); +} +static struct acpi_device *usb_acpi_find_companion (struct device *dev) {struct usb_device *udev;
@@ -174,8 +190,10 @@ static struct acpi_device *usb_acpi_findint raw; raw =usb_hcd_find_raw_port_number (hcd, port1); - adev =acpi_find_child_device (ACPI_COMPANION (&udev->dev), - raw, false); + + adev =usb_acpi_find_port (ACPI_COMPANION (&udev->dev), + raw); +if (!adev)return NULL ; }else {
@@ -186,7 +204,9 @@ static struct acpi_device *usb_acpi_findreturn NULL ;acpi_bus_get_device (parent_handle, &adev); - adev =acpi_find_child_device (adev, port1, false); + + adev =usb_acpi_find_port (adev, port1); +if (!adev)return NULL ; }
Greg Kroah-Hartman
maintainerPATCH 27/27 usb: qmi_wwan: add D-Link DWM-222 device ID
In reply to Greg Kroah-Hartman4.9-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hector Martin <[email protected]>
commit bed9ff165960921303a100228585f2d1691b42eb upstream.
--- drivers/net/usb/qmi_wwan.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/usb/qmi_wwan.c +1 -0
@@ -876,6 +876,7 @@ static const struct usb_device_id produc {QMI_FIXED_INTF(0x19d2, 0x1428, 2)}, /* Telewell TW-LTE 4G v2 */ {QMI_FIXED_INTF(0x19d2, 0x2002, 4)}, /* ZTE (Vodafone) K3765-Z */ {QMI_FIXED_INTF(0x2001, 0x7e19, 4)}, /* D-Link DWM-221 B1 */ + {QMI_FIXED_INTF(0x2001, 0x7e35, 4)}, /* D-Link DWM-222 */ {QMI_FIXED_INTF(0x0f3d, 0x68a2, 8)}, /* Sierra Wireless MC7700 */ {QMI_FIXED_INTF(0x114f, 0x68a2, 8)}, /* Sierra Wireless MC7750 */ {QMI_FIXED_INTF(0x1199, 0x68a2, 8)}, /* Sierra Wireless MC7710 in QMI mode */
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.45 release. There are 27 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu Aug 24 19:13:17 UTC 2017. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.45-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Hi Greg,
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.45 release. There are 27 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu Aug 24 19:13:17 UTC 2017. Anything received after that time might be too late.
For ARM64, built and boot tested with defconfig on Hikey, no regressions noted.
Quoted 10 lines
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.45-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.9.y
and the diffstat can be found below.thanks,
greg k-h
Best,
Sumit.
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.45 release. There are 27 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu Aug 24 19:13:17 UTC 2017. Anything received after that time might be too late.
Build results:
total: 145 pass: 145 fail: 0 Qemu test results: total: 122 pass: 122 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter