Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1717766 > unrolled thread

[PATCH 4.4 00/20] 4.4.84-stable review

Started byGreg Kroah-Hartman <gregkh@linuxfoundation.org>
First post2017-08-22 21:40 +0200
Last post2017-08-23 02:40 +0200
Articles 11 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 4.4 00/20] 4.4.84-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-08-22 21:40 +0200
    [PATCH 4.4 06/20] Input: elan_i2c - Add antoher Lenovo ACPI ID for upcoming Lenovo NB Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-08-22 21:40 +0200
    [PATCH 4.4 02/20] audit: Fix use after free in audit_remove_watch_rule() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-08-22 21:40 +0200
    [PATCH 4.4 05/20] Input: elan_i2c - add ELAN0608 to the ACPI table Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-08-22 21:40 +0200
    [PATCH 4.4 08/20] ALSA: usb-audio: Apply sample rate quirk to Sennheiser headset Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-08-22 21:40 +0200
    [PATCH 4.4 01/20] netfilter: nf_ct_ext: fix possible panic after nf_ct_extend_unregister Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-08-22 21:40 +0200
    [PATCH 4.4 04/20] crypto: x86/sha1 - Fix reads beyond the number of blocks passed Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-08-22 21:40 +0200
    [PATCH 4.4 03/20] parisc: pci memory bar assignment fails with 64bit kernels on dino/cujo Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-08-22 21:40 +0200
    [PATCH 4.4 07/20] ALSA: seq: 2nd attempt at fixing race creating a queue Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-08-22 21:40 +0200
    [PATCH 4.4 10/20] mm/mempolicy: fix use after free when calling get_mempolicy Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-08-22 21:40 +0200
    Re: [PATCH 4.4 00/20] 4.4.84-stable review Shuah Khan <shuahkh@osg.samsung.com> - 2017-08-23 02:40 +0200

#1717766 — [PATCH 4.4 00/20] 4.4.84-stable review

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-08-22 21:40 +0200
Subject[PATCH 4.4 00/20] 4.4.84-stable review
Message-ID<uhmSu-6HP-15@gated-at.bofh.it>
This is the start of the stable review cycle for the 4.4.84 release.
There are 20 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:09:07 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.4.84-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.4.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 4.4.84-rc1

Hector Martin <marcan@marcan.st>
    usb: qmi_wwan: add D-Link DWM-222 device ID

Mathias Nyman <mathias.nyman@linux.intel.com>
    usb: optimize acpi companion search for usb port devices

Stephane Eranian <eranian@google.com>
    perf/x86: Fix LBR related crashes on Intel Atom

Oleg Nesterov <oleg@redhat.com>
    pids: make task_tgid_nr_ns() safe

Linus Torvalds <torvalds@linux-foundation.org>
    Sanitize 'move_pages()' permission checks

Boris Brezillon <boris.brezillon@free-electrons.com>
    irqchip/atmel-aic: Fix unbalanced refcount in aic_common_rtc_irq_fixup()

Boris Brezillon <boris.brezillon@free-electrons.com>
    irqchip/atmel-aic: Fix unbalanced of_node_put() in aic_common_irq_fixup()

Andy Lutomirski <luto@kernel.org>
    x86/asm/64: Clear AC on NMI entries

Roger Pau Monne <roger.pau@citrix.com>
    xen: fix bio vec merging

Kees Cook <keescook@chromium.org>
    mm: revert x86_64 and arm64 ELF_ET_DYN_BASE base changes

zhong jiang <zhongjiang@huawei.com>
    mm/mempolicy: fix use after free when calling get_mempolicy

Takashi Iwai <tiwai@suse.de>
    ALSA: usb-audio: Add mute TLV for playback volumes on C-Media devices

Takashi Iwai <tiwai@suse.de>
    ALSA: usb-audio: Apply sample rate quirk to Sennheiser headset

Daniel Mentz <danielmentz@google.com>
    ALSA: seq: 2nd attempt at fixing race creating a queue

KT Liao <kt.liao@emc.com.tw>
    Input: elan_i2c - Add antoher Lenovo ACPI ID for upcoming Lenovo NB

Kai-Heng Feng <kai.heng.feng@canonical.com>
    Input: elan_i2c - add ELAN0608 to the ACPI table

megha.dey@linux.intel.com <megha.dey@linux.intel.com>
    crypto: x86/sha1 - Fix reads beyond the number of blocks passed

Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    parisc: pci memory bar assignment fails with 64bit kernels on dino/cujo

Jan Kara <jack@suse.cz>
    audit: Fix use after free in audit_remove_watch_rule()

Liping Zhang <zlpnobody@gmail.com>
    netfilter: nf_ct_ext: fix possible panic after nf_ct_extend_unregister


-------------

Diffstat:

 Makefile                                   |  4 +-
 arch/arm64/include/asm/elf.h               |  4 +-
 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 +-
 arch/x86/kernel/cpu/perf_event_intel_lbr.c |  8 ++--
 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/pid.h                        |  4 +-
 include/linux/sched.h                      | 50 ++++++++++++----------
 kernel/audit_watch.c                       | 12 +++---
 kernel/pid.c                               | 11 ++---
 mm/mempolicy.c                             |  5 ---
 mm/migrate.c                               | 11 ++---
 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 +
 27 files changed, 160 insertions(+), 117 deletions(-)

[toc] | [next] | [standalone]


#1717767 — [PATCH 4.4 06/20] Input: elan_i2c - Add antoher Lenovo ACPI ID for upcoming Lenovo NB

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-08-22 21:40 +0200
Subject[PATCH 4.4 06/20] Input: elan_i2c - Add antoher Lenovo ACPI ID for upcoming Lenovo NB
Message-ID<uhnbP-6Qf-13@gated-at.bofh.it>
In reply to#1717766
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: KT Liao <kt.liao@emc.com.tw>

commit 76988690402dde2880bfe06ecccf381d48ba8e1c upstream.

Add 2 new IDs (ELAN0609 and ELAN060B) to the list of ACPI IDs that should
be handled by the driver.

Signed-off-by: KT Liao <kt.liao@emc.com.tw>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/input/mouse/elan_i2c_core.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -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 },
 	{ }
 };

[toc] | [prev] | [next] | [standalone]


#1717770 — [PATCH 4.4 02/20] audit: Fix use after free in audit_remove_watch_rule()

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-08-22 21:40 +0200
Subject[PATCH 4.4 02/20] audit: Fix use after free in audit_remove_watch_rule()
Message-ID<uhnbP-6Qf-21@gated-at.bofh.it>
In reply to#1717766
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jan Kara <jack@suse.cz>

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.

Reported-by: Tony Jones <tonyj@suse.de>
Signed-off-by: Jan Kara <jack@suse.cz>
Tested-by: Tony Jones <tonyj@suse.de>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/audit_watch.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -457,13 +457,15 @@ void audit_remove_watch_rule(struct audi
 	list_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);
 	}
 }
 

[toc] | [prev] | [next] | [standalone]


#1717773 — [PATCH 4.4 05/20] Input: elan_i2c - add ELAN0608 to the ACPI table

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-08-22 21:40 +0200
Subject[PATCH 4.4 05/20] Input: elan_i2c - add ELAN0608 to the ACPI table
Message-ID<uhnbQ-6Qf-23@gated-at.bofh.it>
In reply to#1717766
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Kai-Heng Feng <kai.heng.feng@canonical.com>

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.

BugLink: https://bugs.launchpad.net/bugs/1708852

Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/input/mouse/elan_i2c_core.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -1235,6 +1235,7 @@ static const struct acpi_device_id elan_
 	{ "ELAN0100", 0 },
 	{ "ELAN0600", 0 },
 	{ "ELAN0605", 0 },
+	{ "ELAN0608", 0 },
 	{ "ELAN1000", 0 },
 	{ }
 };

[toc] | [prev] | [next] | [standalone]


#1717774 — [PATCH 4.4 08/20] ALSA: usb-audio: Apply sample rate quirk to Sennheiser headset

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-08-22 21:40 +0200
Subject[PATCH 4.4 08/20] ALSA: usb-audio: Apply sample rate quirk to Sennheiser headset
Message-ID<uhnbQ-6Qf-27@gated-at.bofh.it>
In reply to#1717766
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Takashi Iwai <tiwai@suse.de>

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
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/usb/quirks.c |    1 +
 1 file changed, 1 insertion(+)

--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1143,6 +1143,7 @@ bool snd_usb_get_sample_rate_quirk(struc
 	case 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 */

[toc] | [prev] | [next] | [standalone]


#1717775 — [PATCH 4.4 01/20] netfilter: nf_ct_ext: fix possible panic after nf_ct_extend_unregister

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-08-22 21:40 +0200
Subject[PATCH 4.4 01/20] netfilter: nf_ct_ext: fix possible panic after nf_ct_extend_unregister
Message-ID<uhnbQ-6Qf-37@gated-at.bofh.it>
In reply to#1717766
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Liping Zhang <zlpnobody@gmail.com>

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.

Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/netfilter/nf_conntrack_extend.c |   13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

--- a/net/netfilter/nf_conntrack_extend.c
+++ b/net/netfilter/nf_conntrack_extend.c
@@ -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_c
 
 	rcu_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;
@@ -186,6 +193,6 @@ void nf_ct_extend_unregister(struct nf_c
 	RCU_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);

[toc] | [prev] | [next] | [standalone]


#1717779 — [PATCH 4.4 04/20] crypto: x86/sha1 - Fix reads beyond the number of blocks passed

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-08-22 21:40 +0200
Subject[PATCH 4.4 04/20] crypto: x86/sha1 - Fix reads beyond the number of blocks passed
Message-ID<uhnbQ-6Qf-35@gated-at.bofh.it>
In reply to#1717766
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: megha.dey@linux.intel.com <megha.dey@linux.intel.com>

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 commit
b82ce24426a4071da9529d726057e4e642948667

Fixes: b82ce24426a4 ("crypto: sha1-ssse3 - Disable avx2")
Originally-by: Ilya Albrekht <ilya.albrekht@intel.com>
Tested-by: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Megha Dey <megha.dey@linux.intel.com>
Reported-by: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 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(-)

--- a/arch/x86/crypto/sha1_avx2_x86_64_asm.S
+++ b/arch/x86/crypto/sha1_avx2_x86_64_asm.S
@@ -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
 
--- a/arch/x86/crypto/sha1_ssse3_glue.c
+++ b/arch/x86/crypto/sha1_ssse3_glue.c
@@ -201,7 +201,7 @@ asmlinkage void sha1_transform_avx2(u32
 
 static 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;

[toc] | [prev] | [next] | [standalone]


#1717784 — [PATCH 4.4 03/20] parisc: pci memory bar assignment fails with 64bit kernels on dino/cujo

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-08-22 21:40 +0200
Subject[PATCH 4.4 03/20] parisc: pci memory bar assignment fails with 64bit kernels on dino/cujo
Message-ID<uhnbR-6Qf-55@gated-at.bofh.it>
In reply to#1717766
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>

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.

Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Acked-by: Helge Deller <deller@gmx.de>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/parisc/dino.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/parisc/dino.c
+++ b/drivers/parisc/dino.c
@@ -954,7 +954,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);
 

[toc] | [prev] | [next] | [standalone]


#1717787 — [PATCH 4.4 07/20] ALSA: seq: 2nd attempt at fixing race creating a queue

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-08-22 21:40 +0200
Subject[PATCH 4.4 07/20] ALSA: seq: 2nd attempt at fixing race creating a queue
Message-ID<uhnbR-6Qf-61@gated-at.bofh.it>
In reply to#1717766
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Daniel Mentz <danielmentz@google.com>

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).

Fixes: 4842e98f26dd ("ALSA: seq: Fix race at creating a queue")
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Daniel Mentz <danielmentz@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 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(-)

--- a/sound/core/seq/seq_clientmgr.c
+++ b/sound/core/seq/seq_clientmgr.c
@@ -1530,19 +1530,14 @@ static int snd_seq_ioctl_create_queue(st
 				      void __user *arg)
 {
 	struct snd_seq_queue_info info;
-	int result;
 	struct snd_seq_queue *q;
 
 	if (copy_from_user(&info, arg, sizeof(info)))
 		return -EFAULT;
 
-	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;
@@ -1552,7 +1547,7 @@ static int snd_seq_ioctl_create_queue(st
 	if (! 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);
 
 	if (copy_to_user(arg, &info, sizeof(info)))
 		return -EFAULT;
--- a/sound/core/seq/seq_queue.c
+++ b/sound/core/seq/seq_queue.c
@@ -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 */
--- a/sound/core/seq/seq_queue.h
+++ b/sound/core/seq/seq_queue.h
@@ -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);

[toc] | [prev] | [next] | [standalone]


#1717788 — [PATCH 4.4 10/20] mm/mempolicy: fix use after free when calling get_mempolicy

FromGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Date2017-08-22 21:40 +0200
Subject[PATCH 4.4 10/20] mm/mempolicy: fix use after free when calling get_mempolicy
Message-ID<uhnbR-6Qf-63@gated-at.bofh.it>
In reply to#1717766
4.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: zhong jiang <zhongjiang@huawei.com>

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.

Link: http://lkml.kernel.org/r/1502950924-27521-1-git-send-email-zhongjiang@huawei.com
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: David Rientjes <rientjes@google.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 mm/mempolicy.c |    5 -----
 1 file changed, 5 deletions(-)

--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -894,11 +894,6 @@ static long do_get_mempolicy(int *policy
 		*policy |= (pol->flags & MPOL_MODE_FLAGS);
 	}
 
-	if (vma) {
-		up_read(&current->mm->mmap_sem);
-		vma = NULL;
-	}
-
 	err = 0;
 	if (nmask) {
 		if (mpol_store_user_nodemask(pol)) {

[toc] | [prev] | [next] | [standalone]


#1717918

FromShuah Khan <shuahkh@osg.samsung.com>
Date2017-08-23 02:40 +0200
Message-ID<uhrSa-1HS-11@gated-at.bofh.it>
In reply to#1717766
On 08/22/2017 01:09 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.84 release.
> There are 20 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:09:07 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.4.84-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.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web