Skip to contentSkip to conversation

4.4.121-stable review

PATCH In review Greg Kroah-Hartman 10 participants 56 messages Mar 10, 2018 – Mar 16, 2018

Subsystems (7)
lore
Share & tools
lore

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 4.4.121-stable review

This is the start of the stable review cycle for the 4.4.121 release. There are 36 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 Mon Mar 12 00:17:54 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.121-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 <[email protected]>

    Linux 4.4.121-rc1

Ernesto A. Fernández <[email protected]>
btrfs: preserve i_mode if __btrfs_set_acl() fails

Daniel Borkmann <[email protected]>
bpf, x64: implement retpoline for tail call

Mike Snitzer <[email protected]>
dm io: fix duplicate bio completion due to missing ref count

Dan Williams <[email protected]>
mpls, nospec: Sanitize array index in mpls_label_ok()

David Ahern <[email protected]>
net: mpls: Pull common label check into helper

Alexey Kodanev <[email protected]>
sctp: verify size of a new chunk in _sctp_make_chunk()

Julian Wiedmann <[email protected]>
s390/qeth: fix IPA command submission race

Julian Wiedmann <[email protected]>
s390/qeth: fix SETIP command handling

Alexey Kodanev <[email protected]>
sctp: fix dst refcnt leak in sctp_v6_get_dst()

Tommi Rantala <[email protected]>
sctp: fix dst refcnt leak in sctp_v4_get_dst

Alexey Kodanev <[email protected]>
udplite: fix partial checksum initialization

Guillaume Nault <[email protected]>
ppp: prevent unregistered channels from connecting to PPP units

Nicolas Dichtel <[email protected]>
netlink: ensure to loop over all netns in genlmsg_multicast_allns()

Sabrina Dubroca <[email protected]>
net: ipv4: don't allow setting net.ipv4.route.min_pmtu below 68

Jakub Kicinski <[email protected]>
net: fix race on decreasing number of TX queues

Arnd Bergmann <[email protected]>
ipv6 sit: work around bogus gcc-8 -Wrestrict warning

Denis Du <[email protected]>
hdlc_ppp: carrier detect ok, don't turn off negotiation

Stefano Brivio <[email protected]>
fib_semantics: Don't match route with mismatching tclassid

Xin Long <[email protected]>
bridge: check brport attr show in brport_show

Ben Hutchings <[email protected]>
Revert "led: core: Fix brightness setting when setting delay_off=0"

Dan Carpenter <[email protected]>
x86/spectre: Fix an error message

Nathan Sullivan <[email protected]>
leds: do not overflow sysfs buffer in led_trigger_show

Thomas Gleixner <[email protected]>
x86/apic/vector: Handle legacy irq data correctly

Adam Ford <[email protected]>
ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux

Jan Kara <[email protected]>
btrfs: Don't clear SGID when inheriting ACLs

Jiri Slaby <[email protected]>
x86/syscall: Sanitize syscall table de-references under speculation fix

Wanpeng Li <[email protected]>
KVM: mmu: Fix overlap between public and private memslots

Ulf Magnusson <[email protected]>

    ARM: mvebu: Fix broken PL310_ERRATA_753970 selects

Rasmus Villemoes <[email protected]>
nospec: Allow index argument to have const-qualified type

Mauro Carvalho Chehab <[email protected]>
media: m88ds3103: don't call a non-initalized function

Viresh Kumar <[email protected]>
cpufreq: s3c24xx: Fix broken s3c_cpufreq_init()

Hans de Goede <[email protected]>
ALSA: hda: Add a power_save blacklist

Erik Veijola <[email protected]>
ALSA: usb-audio: Add a quirck for B&W PX headphones

Jeremy Boone <[email protected]>
tpm_i2c_nuvoton: fix potential buffer overruns caused by bit glitches on the bus

Jeremy Boone <[email protected]>
tpm_i2c_infineon: fix potential buffer overruns caused by bit glitches on the bus

Jeremy Boone <[email protected]>
tpm: st33zp24: fix potential buffer overruns caused by bit glitches on the bus

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

Diffstat:

 Makefile                                   |  4 +--
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi |  8 +++++
 arch/arm/mach-mvebu/Kconfig                |  4 +--
 arch/x86/entry/entry_64.S                  | 16 ++++++----
 arch/x86/include/asm/nospec-branch.h       | 37 +++++++++++++++++++++++
 arch/x86/kernel/apic/vector.c              | 14 ++++-----
 arch/x86/kernel/cpu/bugs.c                 |  3 +-
 arch/x86/net/bpf_jit_comp.c                |  9 +++---
 drivers/char/tpm/st33zp24/st33zp24.c       |  4 +--
 drivers/char/tpm/tpm_i2c_infineon.c        |  5 ++--
 drivers/char/tpm/tpm_i2c_nuvoton.c         |  8 +++--
 drivers/cpufreq/s3c24xx-cpufreq.c          |  8 ++++-
 drivers/leds/led-core.c                    |  2 +-
 drivers/leds/led-triggers.c                | 12 ++++----
 drivers/md/dm-io.c                         |  1 +
 drivers/media/dvb-frontends/m88ds3103.c    |  7 +++--
 drivers/net/ppp/ppp_generic.c              |  9 ++++++
 drivers/net/wan/hdlc_ppp.c                 |  5 +++-
 drivers/s390/net/qeth_core.h               |  5 ++++
 drivers/s390/net/qeth_core_main.c          | 33 +++++++++++----------
 fs/btrfs/acl.c                             | 19 +++++++-----
 include/linux/nospec.h                     |  3 +-
 include/net/udplite.h                      |  1 +
 net/bridge/br_sysfs_if.c                   |  3 ++
 net/core/dev.c                             | 11 +++++--
 net/ipv4/fib_semantics.c                   |  5 ++++
 net/ipv4/route.c                           |  8 +++--
 net/ipv4/udp.c                             |  5 ++++
 net/ipv6/ip6_checksum.c                    |  5 ++++
 net/ipv6/sit.c                             |  2 +-
 net/mpls/af_mpls.c                         | 36 +++++++++++++----------
 net/netlink/genetlink.c                    | 12 ++++++--
 net/sctp/ipv6.c                            | 10 +++++--
 net/sctp/protocol.c                        | 10 +++----
 net/sctp/sm_make_chunk.c                   |  8 +++--
 sound/pci/hda/hda_intel.c                  | 38 ++++++++++++++++++++++--
 sound/usb/quirks-table.h                   | 47 ++++++++++++++++++++++++++++++
 virt/kvm/kvm_main.c                        |  3 +-
 38 files changed, 320 insertions(+), 100 deletions(-)
author maintainer
#1 lore raw

PATCH 1/36 tpm: st33zp24: fix potential buffer overruns caused by bit glitches on the bus

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Jeremy Boone <[email protected]>

commit 6d24cd186d9fead3722108dec1b1c993354645ff upstream.

Discrete TPMs are often connected over slow serial buses which, on some platforms, can have glitches causing bit flips. In all the driver _recv() functions, we need to use a u32 to unmarshal the response size, otherwise a bit flip of the 31st bit would cause the expected variable to go negative, which would then try to read a huge amount of data. Also sanity check that the expected amount of data is large enough for the TPM header.

---
 drivers/char/tpm/st33zp24/st33zp24.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/char/tpm/st33zp24/st33zp24.c +2 -2
@@ -485,7 +485,7 @@ static int st33zp24_recv(struct tpm_chip
 			    size_t count)
 {
 	int size = 0;
-	int expected;
+	u32 expected;
 
 	if (!chip)
 		return -EBUSY;
@@ -502,7 +502,7 @@ static int st33zp24_recv(struct tpm_chip
 	}
 
 	expected = be32_to_cpu(*(__be32 *)(buf + 2));
-	if (expected > count) {
+	if (expected > count || expected < TPM_HEADER_SIZE) {
 		size = -EIO;
 		goto out;
 	}
author maintainer
#2 lore raw

PATCH 2/36 tpm_i2c_infineon: fix potential buffer overruns caused by bit glitches on the bus

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Jeremy Boone <[email protected]>

commit 9b8cb28d7c62568a5916bdd7ea1c9176d7f8f2ed upstream.

Discrete TPMs are often connected over slow serial buses which, on some platforms, can have glitches causing bit flips. In all the driver _recv() functions, we need to use a u32 to unmarshal the response size, otherwise a bit flip of the 31st bit would cause the expected variable to go negative, which would then try to read a huge amount of data. Also sanity check that the expected amount of data is large enough for the TPM header.

---
 drivers/char/tpm/tpm_i2c_infineon.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/char/tpm/tpm_i2c_infineon.c +3 -2
@@ -436,7 +436,8 @@ static int recv_data(struct tpm_chip *ch
 static int tpm_tis_i2c_recv(struct tpm_chip *chip, u8 *buf, size_t count)
 {
 	int size = 0;
-	int expected, status;
+	int status;
+	u32 expected;
 
 	if (count < TPM_HEADER_SIZE) {
 		size = -EIO;
@@ -451,7 +452,7 @@ static int tpm_tis_i2c_recv(struct tpm_c
 	}
 
 	expected = be32_to_cpu(*(__be32 *)(buf + 2));
-	if ((size_t) expected > count) {
+	if (((size_t) expected > count) || (expected < TPM_HEADER_SIZE)) {
 		size = -EIO;
 		goto out;
 	}
author maintainer
#3 lore raw

PATCH 3/36 tpm_i2c_nuvoton: fix potential buffer overruns caused by bit glitches on the bus

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Jeremy Boone <[email protected]>

commit f9d4d9b5a5ef2f017bc344fb65a58a902517173b upstream.

Discrete TPMs are often connected over slow serial buses which, on some platforms, can have glitches causing bit flips. In all the driver _recv() functions, we need to use a u32 to unmarshal the response size, otherwise a bit flip of the 31st bit would cause the expected variable to go negative, which would then try to read a huge amount of data. Also sanity check that the expected amount of data is large enough for the TPM header.

---
 drivers/char/tpm/tpm_i2c_nuvoton.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/char/tpm/tpm_i2c_nuvoton.c +6 -2
@@ -267,7 +267,11 @@ static int i2c_nuvoton_recv(struct tpm_c
 	struct device *dev = chip->dev.parent;
 	struct i2c_client *client = to_i2c_client(dev);
 	s32 rc;
-	int expected, status, burst_count, retries, size = 0;
+	int status;
+	int burst_count;
+	int retries;
+	int size = 0;
+	u32 expected;
 
 	if (count < TPM_HEADER_SIZE) {
 		i2c_nuvoton_ready(chip);    /* return to idle */
@@ -309,7 +313,7 @@ static int i2c_nuvoton_recv(struct tpm_c
 		 * to machine native
 		 */
 		expected = be32_to_cpu(*(__be32 *) (buf + 2));
-		if (expected > count) {
+		if (expected > count || expected < size) {
 			dev_err(dev, "%s() expected > count\n", __func__);
 			size = -EIO;
 			continue;
author maintainer
#4 lore raw

PATCH 4/36 ALSA: usb-audio: Add a quirck for B&W PX headphones

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Erik Veijola <[email protected]>

commit 240a8af929c7c57dcde28682725b29cf8474e8e5 upstream.

The capture interface doesn't work and the playback interface only supports 48 kHz sampling rate even though it advertises more rates.

---
 sound/usb/quirks-table.h |   47 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)
sound/usb/quirks-table.h +47 -0
@@ -3277,4 +3277,51 @@ AU0828_DEVICE(0x2040, 0x7270, "Hauppauge
 	}
 },
 
+{
+	/*
+	 * Bower's & Wilkins PX headphones only support the 48 kHz sample rate
+	 * even though it advertises more. The capture interface doesn't work
+	 * even on windows.
+	 */
+	USB_DEVICE(0x19b5, 0x0021),
+	.driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) {
+		.ifnum = QUIRK_ANY_INTERFACE,
+		.type = QUIRK_COMPOSITE,
+		.data = (const struct snd_usb_audio_quirk[]) {
+			{
+				.ifnum = 0,
+				.type = QUIRK_AUDIO_STANDARD_MIXER,
+			},
+			/* Capture */
+			{
+				.ifnum = 1,
+				.type = QUIRK_IGNORE_INTERFACE,
+			},
+			/* Playback */
+			{
+				.ifnum = 2,
+				.type = QUIRK_AUDIO_FIXED_ENDPOINT,
+				.data = &(const struct audioformat) {
+					.formats = SNDRV_PCM_FMTBIT_S16_LE,
+					.channels = 2,
+					.iface = 2,
+					.altsetting = 1,
+					.altset_idx = 1,
+					.attributes = UAC_EP_CS_ATTR_FILL_MAX |
+						UAC_EP_CS_ATTR_SAMPLE_RATE,
+					.endpoint = 0x03,
+					.ep_attr = USB_ENDPOINT_XFER_ISOC,
+					.rates = SNDRV_PCM_RATE_48000,
+					.rate_min = 48000,
+					.rate_max = 48000,
+					.nr_rates = 1,
+					.rate_table = (unsigned int[]) {
+						48000
+					}
+				}
+			},
+		}
+	}
+},
+
 #undef USB_DEVICE_VENDOR_SPEC
author maintainer
#5 lore raw

PATCH 5/36 ALSA: hda: Add a power_save blacklist

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Hans de Goede <[email protected]>

commit 1ba8f9d308174e647b864c36209b4d7934d99888 upstream.

On some boards setting power_save to a non 0 value leads to clicking / popping sounds when ever we enter/leave powersaving mode. Ideally we would figure out how to avoid these sounds, but that is not always feasible.

This commit adds a blacklist for devices where powersaving is known to cause problems and disables it on these devices.

Note I tried to put this blacklist in userspace first:
https://github.com/systemd/systemd/pull/8128

But the systemd maintainers rightfully pointed out that it would be impossible to then later remove entries once we actually find a way to make power-saving work on listed boards without issues. Having this list in the kernel will allow removal of the blacklist entry in the same commit which fixes the clicks / plops.

The blacklist only applies to the default power_save module-option value, if a user explicitly sets the module-option then the blacklist is not used.

[ added an ifdef CONFIG_PM for the build error -- tiwai]

---
 sound/pci/hda/hda_intel.c |   38 ++++++++++++++++++++++++++++++++++++--
 1 file changed, 36 insertions(+), 2 deletions(-)
sound/pci/hda/hda_intel.c +36 -2
@@ -179,7 +179,7 @@ static const struct kernel_param_ops par
 };
 #define param_check_xint param_check_int
 
-static int power_save = CONFIG_SND_HDA_POWER_SAVE_DEFAULT;
+static int power_save = -1;
 module_param(power_save, xint, 0644);
 MODULE_PARM_DESC(power_save, "Automatic power-saving timeout "
 		 "(in second, 0 = disable).");
@@ -2055,6 +2055,24 @@ out_free:
 	return err;
 }
 
+#ifdef CONFIG_PM
+/* On some boards setting power_save to a non 0 value leads to clicking /
+ * popping sounds when ever we enter/leave powersaving mode. Ideally we would
+ * figure out how to avoid these sounds, but that is not always feasible.
+ * So we keep a list of devices where we disable powersaving as its known
+ * to causes problems on these devices.
+ */
+static struct snd_pci_quirk power_save_blacklist[] = {
+	/* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */
+	SND_PCI_QUIRK(0x1849, 0x0c0c, "Asrock B85M-ITX", 0),
+	/* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */
+	SND_PCI_QUIRK(0x1043, 0x8733, "Asus Prime X370-Pro", 0),
+	/* https://bugzilla.kernel.org/show_bug.cgi?id=198611 */
+	SND_PCI_QUIRK(0x17aa, 0x2227, "Lenovo X1 Carbon 3rd Gen", 0),
+	{}
+};
+#endif /* CONFIG_PM */
+
 /* number of codec slots for each chipset: 0 = default slots (i.e. 4) */
 static unsigned int azx_max_codecs[AZX_NUM_DRIVERS] = {
 	[AZX_DRIVER_NVIDIA] = 8,
@@ -2067,6 +2085,7 @@ static int azx_probe_continue(struct azx
 	struct hdac_bus *bus = azx_bus(chip);
 	struct pci_dev *pci = chip->pci;
 	int dev = chip->dev_index;
+	int val;
 	int err;
 
 	hda->probe_continued = 1;
@@ -2142,7 +2161,22 @@ static int azx_probe_continue(struct azx
 
 	chip->running = 1;
 	azx_add_card_list(chip);
-	snd_hda_set_power_save(&chip->bus, power_save * 1000);
+
+	val = power_save;
+#ifdef CONFIG_PM
+	if (val == -1) {
+		const struct snd_pci_quirk *q;
+
+		val = CONFIG_SND_HDA_POWER_SAVE_DEFAULT;
+		q = snd_pci_quirk_lookup(chip->pci, power_save_blacklist);
+		if (q && val) {
+			dev_info(chip->card->dev, "device %04x:%04x is on the power_save blacklist, forcing power_save to 0\n",
+				 q->subvendor, q->subdevice);
+			val = 0;
+		}
+	}
+#endif /* CONFIG_PM */
+	snd_hda_set_power_save(&chip->bus, val * 1000);
 	if (azx_has_pm_runtime(chip) || hda->use_vga_switcheroo)
 		pm_runtime_put_noidle(&pci->dev);
 
author maintainer
#6 lore raw

PATCH 6/36 cpufreq: s3c24xx: Fix broken s3c_cpufreq_init()

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Viresh Kumar <[email protected]>

commit 0373ca74831b0f93cd4cdbf7ad3aec3c33a479a5 upstream.

commit a307a1e6bc0d "cpufreq: s3c: use cpufreq_generic_init()" accidentally broke cpufreq on s3c2410 and s3c2412.

These two platforms don't have a CPU frequency table and used to skip calling cpufreq_table_validate_and_show() for them. But with the above commit, we started calling it unconditionally and that will eventually fail as the frequency table pointer is NULL.

Fix this by calling cpufreq_table_validate_and_show() conditionally again.

Fixes a307a1e6bc0d "cpufreq: s3c: use cpufreq_generic_init()"
Cc 3.13+ <[email protected]> # v3.13+
---
 drivers/cpufreq/s3c24xx-cpufreq.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/cpufreq/s3c24xx-cpufreq.c +7 -1
@@ -364,7 +364,13 @@ struct clk *s3c_cpufreq_clk_get(struct d
 static int s3c_cpufreq_init(struct cpufreq_policy *policy)
 {
 	policy->clk = clk_arm;
-	return cpufreq_generic_init(policy, ftab, cpu_cur.info->latency);
+
+	policy->cpuinfo.transition_latency = cpu_cur.info->latency;
+
+	if (ftab)
+		return cpufreq_table_validate_and_show(policy, ftab);
+
+	return 0;
 }
 
 static int __init s3c_cpufreq_initclks(void)
author maintainer
#7 lore raw

PATCH 7/36 media: m88ds3103: dont call a non-initalized function

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Mauro Carvalho Chehab <[email protected]>

commit b9c97c67fd19262c002d94ced2bfb513083e161e upstream.

If m88d3103 chip ID is not recognized, the device is not initialized.

However, it returns from probe without any error, causing this OOPS:

[    7.689289] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[    7.689297] pgd = 7b0bd7a7
[    7.689302] [00000000] *pgd=00000000
[    7.689318] Internal error: Oops: 80000005 [#1] SMP ARM
[    7.689322] Modules linked in: dvb_usb_dvbsky(+) m88ds3103 dvb_usb_v2 dvb_core videobuf2_vmalloc videobuf2_memops videobuf2_core crc32_arm_ce videodev media
[    7.689358] CPU: 3 PID: 197 Comm: systemd-udevd Not tainted 4.15.0-mcc+ #23
[    7.689361] Hardware name: BCM2835
[    7.689367] PC is at 0x0
[    7.689382] LR is at m88ds3103_attach+0x194/0x1d0 [m88ds3103]
[    7.689386] pc : [<00000000>]    lr : [<bf0ae1ec>]    psr: 60000013
[    7.689391] sp : ed8e5c20  ip : ed8c1e00  fp : ed8945c0
[    7.689395] r10: ed894000  r9 : ed894378  r8 : eda736c0
[    7.689400] r7 : ed894070  r6 : ed8e5c44  r5 : bf0bb040  r4 : eda77600
[    7.689405] r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : eda77600
[    7.689412] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[    7.689417] Control: 10c5383d  Table: 2d8e806a  DAC: 00000051
[    7.689423] Process systemd-udevd (pid: 197, stack limit = 0xe9dbfb63)
[    7.689428] Stack: (0xed8e5c20 to 0xed8e6000)
[    7.689439] 5c20: ed853a80 eda73640 ed894000 ed8942c0 ed853a80 bf0b9e98 ed894070 bf0b9f10
[    7.689449] 5c40: 00000000 00000000 bf08c17c c08dfc50 00000000 00000000 00000000 00000000
[    7.689459] 5c60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    7.689468] 5c80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    7.689479] 5ca0: 00000000 00000000 ed8945c0 ed8942c0 ed894000 ed894830 bf0b9e98 00000000
[    7.689490] 5cc0: ed894378 bf0a3cb4 bf0bc3b0 0000533b ed920540 00000000 00000034 bf0a6434
[    7.689500] 5ce0: ee952070 ed826600 bf0a7038 bf0a2dd8 00000001 bf0a6768 bf0a2f90 ed8943c0
[    7.689511] 5d00: 00000000 c08eca68 ed826620 ed826620 00000000 ee952070 bf0bc034 ee952000
[    7.689521] 5d20: ed826600 bf0bb080 ffffffed c0aa9e9c c0aa9dac ed826620 c16edf6c c168c2c8
[    7.689531] 5d40: c16edf70 00000000 bf0bc034 0000000d 00000000 c08e268c bf0bb080 ed826600
[    7.689541] 5d60: bf0bc034 ed826654 ed826620 bf0bc034 c164c8bc 00000000 00000001 00000000
[    7.689553] 5d80: 00000028 c08e2948 00000000 bf0bc034 c08e2848 c08e0778 ee9f0a58 ed88bab4
[    7.689563] 5da0: bf0bc034 ed90ba80 c168c1f0 c08e1934 bf0bb3bc c17045ac bf0bc034 c164c8bc
[    7.689574] 5dc0: bf0bc034 bf0bb3bc ed91f564 c08e34ec bf0bc000 c164c8bc bf0bc034 c0aa8dc4
[    7.689584] 5de0: ffffe000 00000000 bf0bf000 ed91f600 ed91f564 c03021e4 00000001 00000000
[    7.689595] 5e00: c166e040 8040003f ed853a80 bf0bc448 00000000 c1678174 ed853a80 f0f22000
[    7.689605] 5e20: f0f21fff 8040003f 014000c0 ed91e700 ed91e700 c16d8e68 00000001 ed91e6c0
[    7.689615] 5e40: bf0bc400 00000001 bf0bc400 ed91f564 00000001 00000000 00000028 c03c9a24
[    7.689625] 5e60: 00000001 c03c8c94 ed8e5f50 ed8e5f50 00000001 bf0bc400 ed91f540 c03c8cb0
[    7.689637] 5e80: bf0bc40c 00007fff bf0bc400 c03c60b0 00000000 bf0bc448 00000028 c0e09684
[    7.689647] 5ea0: 00000002 bf0bc530 c1234bf8 bf0bc5dc bf0bc514 c10ebbe8 ffffe000 bf000000
[    7.689657] 5ec0: 00011538 00000000 ed8e5f48 00000000 00000000 00000000 00000000 00000000
[    7.689666] 5ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    7.689676] 5f00: 00000000 00000000 7fffffff 00000000 00000013 b6e55a18 0000017b c0309104
[    7.689686] 5f20: ed8e4000 00000000 00510af0 c03c9430 7fffffff 00000000 00000003 00000000
[    7.689697] 5f40: 00000000 f0f0f000 00011538 00000000 f0f107b0 f0f0f000 00011538 f0f1fdb8
[    7.689707] 5f60: f0f1fbe8 f0f1b974 00004000 000041e0 bf0bc3d0 00000001 00000000 000024c4
[    7.689717] 5f80: 0000002d 0000002e 00000019 00000000 00000010 00000000 16894000 00000000
[    7.689727] 5fa0: 00000000 c0308f20 16894000 00000000 00000013 b6e55a18 00000000 b6e5652c
[    7.689737] 5fc0: 16894000 00000000 00000000 0000017b 00020000 00508110 00000000 00510af0
[    7.689748] 5fe0: bef68948 bef68938 b6e4d3d0 b6d32590 60000010 00000013 00000000 00000000
[    7.689790] [<bf0ae1ec>] (m88ds3103_attach [m88ds3103]) from [<bf0b9f10>] (dvbsky_s960c_attach+0x78/0x280 [dvb_usb_dvbsky])
[    7.689821] [<bf0b9f10>] (dvbsky_s960c_attach [dvb_usb_dvbsky]) from [<bf0a3cb4>] (dvb_usbv2_probe+0xa3c/0x1024 [dvb_usb_v2])
[    7.689849] [<bf0a3cb4>] (dvb_usbv2_probe [dvb_usb_v2]) from [<c0aa9e9c>] (usb_probe_interface+0xf0/0x2a8)
[    7.689869] [<c0aa9e9c>] (usb_probe_interface) from [<c08e268c>] (driver_probe_device+0x2f8/0x4b4)
[    7.689881] [<c08e268c>] (driver_probe_device) from [<c08e2948>] (__driver_attach+0x100/0x11c)
[    7.689895] [<c08e2948>] (__driver_attach) from [<c08e0778>] (bus_for_each_dev+0x4c/0x9c)
[    7.689909] [<c08e0778>] (bus_for_each_dev) from [<c08e1934>] (bus_add_driver+0x1c0/0x264)
[    7.689919] [<c08e1934>] (bus_add_driver) from [<c08e34ec>] (driver_register+0x78/0xf4)
[    7.689931] [<c08e34ec>] (driver_register) from [<c0aa8dc4>] (usb_register_driver+0x70/0x134)
[    7.689946] [<c0aa8dc4>] (usb_register_driver) from [<c03021e4>] (do_one_initcall+0x44/0x168)
[    7.689963] [<c03021e4>] (do_one_initcall) from [<c03c9a24>] (do_init_module+0x64/0x1f4)
[    7.689979] [<c03c9a24>] (do_init_module) from [<c03c8cb0>] (load_module+0x20a0/0x25c8)
[    7.689993] [<c03c8cb0>] (load_module) from [<c03c9430>] (SyS_finit_module+0xb4/0xec)
[    7.690007] [<c03c9430>] (SyS_finit_module) from [<c0308f20>] (ret_fast_syscall+0x0/0x54)
[    7.690018] Code: bad PC value

This may happen on normal circumstances, if, for some reason, the demod hangs and start returning an invalid chip ID:

[   10.394395] m88ds3103 3-0068: Unknown device. Chip_id=00

So, change the logic to cause probe to fail with -ENODEV, preventing the OOPS.

Detected while testing DVB MMAP patches on Raspberry Pi 3 with DVBSky S960CI.

---
 drivers/media/dvb-frontends/m88ds3103.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/media/dvb-frontends/m88ds3103.c +5 -2
@@ -1281,11 +1281,12 @@ static int m88ds3103_select(struct i2c_a
  * New users must use I2C client binding directly!
  */
 struct dvb_frontend *m88ds3103_attach(const struct m88ds3103_config *cfg,
-		struct i2c_adapter *i2c, struct i2c_adapter **tuner_i2c_adapter)
+				      struct i2c_adapter *i2c,
+				      struct i2c_adapter **tuner_i2c_adapter)
 {
 	struct i2c_client *client;
 	struct i2c_board_info board_info;
-	struct m88ds3103_platform_data pdata;
+	struct m88ds3103_platform_data pdata = {};
 
 	pdata.clk = cfg->clock;
 	pdata.i2c_wr_max = cfg->i2c_wr_max;
@@ -1428,6 +1429,8 @@ static int m88ds3103_probe(struct i2c_cl
 	case M88DS3103_CHIP_ID:
 		break;
 	default:
+		ret = -ENODEV;
+		dev_err(&client->dev, "Unknown device. Chip_id=%02x\n", dev->chip_id);
 		goto err_kfree;
 	}
 
author maintainer
#8 lore raw

PATCH 8/36 nospec: Allow index argument to have const-qualified type

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Rasmus Villemoes <[email protected]>

commit b98c6a160a057d5686a8c54c79cc6c8c94a7d0c8 upstream.

The last expression in a statement expression need not be a bare variable, quoting gcc docs

The last thing in the compound statement should be an expression followed by a semicolon; the value of this subexpression serves as the value of the entire construct.

and we already use that in e.g. the min/max macros which end with a ternary expression.

This way, we can allow index to have const-qualified type, which will in some cases avoid the need for introducing a local copy of index of non-const qualified type. That, in turn, can prevent readers not familiar with the internals of array_index_nospec from wondering about the seemingly redundant extra variable, and I think that's worthwhile considering how confusing the whole _nospec business is.

The expression _i&_mask has type unsigned long (since that is the type of _mask, and the BUILD_BUG_ONs guarantee that _i will get promoted to that), so in order not to change the type of the whole expression, add a cast back to typeof(_i).

---
 include/linux/nospec.h |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
include/linux/nospec.h +1 -2
@@ -66,7 +66,6 @@ static inline unsigned long array_index_
 	BUILD_BUG_ON(sizeof(_i) > sizeof(long));			\
 	BUILD_BUG_ON(sizeof(_s) > sizeof(long));			\
 									\
-	_i &= _mask;							\
-	_i;								\
+	(typeof(_i)) (_i & _mask);					\
 })
 #endif /* _LINUX_NOSPEC_H */
author maintainer
#9 lore raw

PATCH 9/36 ARM: mvebu: Fix broken PL310_ERRATA_753970 selects

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Ulf Magnusson <[email protected]>

commit 8aa36a8dcde3183d84db7b0d622ffddcebb61077 upstream.

The MACH_ARMADA_375 and MACH_ARMADA_38X boards select ARM_ERRATA_753970, but it was renamed to PL310_ERRATA_753970 by commit fa0ce4035d48 ("ARM:
7162/1: errata: tidy up Kconfig options for PL310 errata workarounds").

Fix the selects to use the new name.

Discovered with the
https://github.com/ulfalizer/Kconfiglib/blob/master/examples/list_undefined.py
script.

Fixes fa0ce4035d48 ("ARM: 7162/1: errata: tidy up Kconfig options for

PL310 errata workarounds"

---
 arch/arm/mach-mvebu/Kconfig |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/mach-mvebu/Kconfig +2 -2
@@ -37,7 +37,7 @@ config MACH_ARMADA_370
 config MACH_ARMADA_375
 	bool "Marvell Armada 375 boards" if ARCH_MULTI_V7
 	select ARM_ERRATA_720789
-	select ARM_ERRATA_753970
+	select PL310_ERRATA_753970
 	select ARM_GIC
 	select ARMADA_375_CLK
 	select HAVE_ARM_SCU
@@ -52,7 +52,7 @@ config MACH_ARMADA_375
 config MACH_ARMADA_38X
 	bool "Marvell Armada 380/385 boards" if ARCH_MULTI_V7
 	select ARM_ERRATA_720789
-	select ARM_ERRATA_753970
+	select PL310_ERRATA_753970
 	select ARM_GIC
 	select ARMADA_38X_CLK
 	select HAVE_ARM_SCU
author maintainer
#10 lore raw

PATCH 10/36 KVM: mmu: Fix overlap between public and private memslots

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Wanpeng Li <[email protected]>

commit b28676bb8ae4569cced423dc2a88f7cb319d5379 upstream.

Reported by syzkaller:

    pte_list_remove: ffff9714eb1f8078 0->BUG
    ------------[ cut here ]------------
    kernel BUG at arch/x86/kvm/mmu.c:1157!
    invalid opcode: 0000 [#1] SMP
    RIP: 0010:pte_list_remove+0x11b/0x120 [kvm]
    Call Trace:
     drop_spte+0x83/0xb0 [kvm]
     mmu_page_zap_pte+0xcc/0xe0 [kvm]
     kvm_mmu_prepare_zap_page+0x81/0x4a0 [kvm]
     kvm_mmu_invalidate_zap_all_pages+0x159/0x220 [kvm]
     kvm_arch_flush_shadow_all+0xe/0x10 [kvm]
     kvm_mmu_notifier_release+0x6c/0xa0 [kvm]
     ? kvm_mmu_notifier_release+0x5/0xa0 [kvm]
     __mmu_notifier_release+0x79/0x110
     ? __mmu_notifier_release+0x5/0x110
     exit_mmap+0x15a/0x170
     ? do_exit+0x281/0xcb0
     mmput+0x66/0x160
     do_exit+0x2c9/0xcb0
     ? __context_tracking_exit.part.5+0x4a/0x150
     do_group_exit+0x50/0xd0
     SyS_exit_group+0x14/0x20
     do_syscall_64+0x73/0x1f0
     entry_SYSCALL64_slow_path+0x25/0x25

The reason is that when creates new memslot, there is no guarantee for new memslot not overlap with private memslots. This can be triggered by the following program:

   #include <fcntl.h>
   #include <pthread.h>
   #include <setjmp.h>
   #include <signal.h>
   #include <stddef.h>
   #include <stdint.h>
   #include <stdio.h>
   #include <stdlib.h>
   #include <string.h>
   #include <sys/ioctl.h>
   #include <sys/stat.h>
   #include <sys/syscall.h>
   #include <sys/types.h>
   #include <unistd.h>
   #include <linux/kvm.h>

   long r[16];

int main()

   {
	void *p = valloc(0x4000);

	r[2] = open("/dev/kvm", 0);
	r[3] = ioctl(r[2], KVM_CREATE_VM, 0x0ul);

	uint64_t addr = 0xf000;
	ioctl(r[3], KVM_SET_IDENTITY_MAP_ADDR, &addr);
	r[6] = ioctl(r[3], KVM_CREATE_VCPU, 0x0ul);
	ioctl(r[3], KVM_SET_TSS_ADDR, 0x0ul);
	ioctl(r[6], KVM_RUN, 0);
	ioctl(r[6], KVM_RUN, 0);

	struct kvm_userspace_memory_region mr = {
		.slot = 0,
		.flags = KVM_MEM_LOG_DIRTY_PAGES,
		.guest_phys_addr = 0xf000,
		.memory_size = 0x4000,
		.userspace_addr = (uintptr_t) p
	};
	ioctl(r[3], KVM_SET_USER_MEMORY_REGION, &mr);
	return 0;

}

This patch fixes the bug by not adding a new memslot even if it overlaps with private memslots.

Cc Paolo Bonzini <[email protected]>
Cc Radim Krčmář <[email protected]>
Cc Dmitry Vyukov <[email protected]>
Cc Eric Biggers <[email protected]>
---
 virt/kvm/kvm_main.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
virt/kvm/kvm_main.c +1 -2
@@ -902,8 +902,7 @@ int __kvm_set_memory_region(struct kvm *
 		/* Check for overlaps */
 		r = -EEXIST;
 		kvm_for_each_memslot(slot, __kvm_memslots(kvm, as_id)) {
-			if ((slot->id >= KVM_USER_MEM_SLOTS) ||
-			    (slot->id == id))
+			if (slot->id == id)
 				continue;
 			if (!((base_gfn + npages <= slot->base_gfn) ||
 			      (base_gfn >= slot->base_gfn + slot->npages)))
author maintainer
#11 lore raw

PATCH 11/36 x86/syscall: Sanitize syscall table de-references under speculation fix

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Jiri Slaby <[email protected]>

In 4.4.118, we have commit c8961332d6da (x86/syscall: Sanitize syscall table de-references under speculation), which is a backport of upstream commit 2fbd7af5af86. But it fixed only the C part of the upstream patch -- the IA32 sysentry. So it ommitted completely the assembly part -- the 64bit sysentry.

Fix that in this patch by explicit array_index_mask_nospec written in assembly. The same was used in lib/getuser.S.

However, to have "sbb" working properly, we have to switch from "cmp" against (NR_syscalls-1) to (NR_syscalls), otherwise the last syscall number would be "and"ed by 0. It is because the original "ja" relies on "CF" or "ZF", but we rely only on "CF" in "sbb". That means: switch to "jae" conditional jump too.

Final note: use rcx for mask as this is exactly what is overwritten by the 4th syscall argument (r10) right after.

---
 arch/x86/entry/entry_64.S |   16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)
arch/x86/entry/entry_64.S +10 -6
@@ -178,12 +178,14 @@ GLOBAL(entry_SYSCALL_64_after_swapgs)
 	jnz	tracesys
 entry_SYSCALL_64_fastpath:
 #if __SYSCALL_MASK == ~0
-	cmpq	$__NR_syscall_max, %rax
+	cmpq	$NR_syscalls, %rax
 #else
 	andl	$__SYSCALL_MASK, %eax
-	cmpl	$__NR_syscall_max, %eax
+	cmpl	$NR_syscalls, %eax
 #endif
-	ja	1f				/* return -ENOSYS (already in pt_regs->ax) */
+	jae	1f				/* return -ENOSYS (already in pt_regs->ax) */
+	sbb	%rcx, %rcx			/* array_index_mask_nospec() */
+	and	%rcx, %rax
 	movq	%r10, %rcx
 #ifdef CONFIG_RETPOLINE
 	movq	sys_call_table(, %rax, 8), %rax
@@ -276,12 +278,14 @@ tracesys_phase2:
 	RESTORE_C_REGS_EXCEPT_RAX
 	RESTORE_EXTRA_REGS
 #if __SYSCALL_MASK == ~0
-	cmpq	$__NR_syscall_max, %rax
+	cmpq	$NR_syscalls, %rax
 #else
 	andl	$__SYSCALL_MASK, %eax
-	cmpl	$__NR_syscall_max, %eax
+	cmpl	$NR_syscalls, %eax
 #endif
-	ja	1f				/* return -ENOSYS (already in pt_regs->ax) */
+	jae	1f				/* return -ENOSYS (already in pt_regs->ax) */
+	sbb	%rcx, %rcx			/* array_index_mask_nospec() */
+	and	%rcx, %rax
 	movq	%r10, %rcx			/* fixup for C */
 #ifdef CONFIG_RETPOLINE
 	movq	sys_call_table(, %rax, 8), %rax
author maintainer
#12 lore raw

PATCH 12/36 btrfs: Dont clear SGID when inheriting ACLs

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Jan Kara <[email protected]>

commit b7f8a09f8097db776b8d160862540e4fc1f51296 upstream.

When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit set, DIR1 is expected to have SGID bit set (and owning group equal to the owning group of 'DIR0'). However when 'DIR0' also has some default ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on 'DIR1' to get cleared if user is not member of the owning group.

Fix the problem by moving posix_acl_update_mode() out of __btrfs_set_acl() into btrfs_set_acl(). That way the function will not be called when inheriting ACLs which is what we want as it prevents SGID bit clearing and the mode has been properly set by posix_acl_create() anyway.

---
 fs/btrfs/acl.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)
fs/btrfs/acl.c +7 -6
@@ -82,12 +82,6 @@ static int __btrfs_set_acl(struct btrfs_
 	switch (type) {
 	case ACL_TYPE_ACCESS:
 		name = POSIX_ACL_XATTR_ACCESS;
-		if (acl) {
-			ret = posix_acl_update_mode(inode, &inode->i_mode, &acl);
-			if (ret)
-				return ret;
-		}
-		ret = 0;
 		break;
 	case ACL_TYPE_DEFAULT:
 		if (!S_ISDIR(inode->i_mode))
@@ -123,6 +117,13 @@ out:
 
 int btrfs_set_acl(struct inode *inode, struct posix_acl *acl, int type)
 {
+	int ret;
+
+	if (type == ACL_TYPE_ACCESS && acl) {
+		ret = posix_acl_update_mode(inode, &inode->i_mode, &acl);
+		if (ret)
+			return ret;
+	}
 	return __btrfs_set_acl(NULL, inode, acl, type);
 }
 
author maintainer
#13 lore raw

PATCH 13/36 ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Adam Ford <[email protected]>

commit 74402055a2d3ec998a1ded599e86185a27d9bbf4 upstream.

The pinmuxing was missing for I2C1 which was causing intermittent issues with the PMIC which is connected to I2C1. The bootloader did not quite configure the I2C1 either, so when running at 2.6MHz, it was generating errors at time.

This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz

Fixes 687c27676151 ("ARM: dts: Add minimal support for LogicPD Torpedo

DM3730 devkit")

---
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi |    8 ++++++++
 1 file changed, 8 insertions(+)
arch/arm/boot/dts/logicpd-torpedo-som.dtsi +8 -0
@@ -90,6 +90,8 @@
 };
 
 &i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins>;
 	clock-frequency = <2600000>;
 
 	twl: twl@48 {
@@ -146,6 +148,12 @@
 			OMAP3630_CORE2_IOPAD(0x25da, PIN_INPUT_PULLUP | MUX_MODE2)   /* etk_ctl.sdmmc3_cmd */
 		>;
 	};
+	i2c1_pins: pinmux_i2c1_pins {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0)        /* i2c1_scl.i2c1_scl */
+			OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0)        /* i2c1_sda.i2c1_sda */
+		>;
+	};
 };
 
 #include "twl4030.dtsi"
#14 lore raw

Re: [PATCH 4.4 13/36] ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux

Quoted 41 lines · Greg Kroah-Hartman

4.4-stable review patch.  If anyone has any objections, please let me know.

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

From: Adam Ford <[email protected]>

commit 74402055a2d3ec998a1ded599e86185a27d9bbf4 upstream.

The pinmuxing was missing for I2C1 which was causing intermittent issues with the PMIC which is connected to I2C1.  The bootloader did not quite configure the I2C1 either, so when running at 2.6MHz, it was generating errors at time.

This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz

Fixes 687c27676151 ("ARM: dts: Add minimal support for LogicPD Torpedo

DM3730 devkit")

---
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi |    8 ++++++++

 1 file changed, 8 insertions(+)
arch/arm/boot/dts/logicpd-torpedo-som.dtsi +0 -0
@@ -90,6 +90,8 @@
  };


 &i2c1 {

arch/arm/boot/dts/logicpd-torpedo-som.dtsi +2 -0
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins>;

  clock-frequency = <2600000>;

  twl: twl@48 {

arch/arm/boot/dts/logicpd-torpedo-som.dtsi +0 -0
@@ -146,6 +148,12 @@

  OMAP3630_CORE2_IOPAD(0x25da, PIN_INPUT_PULLUP | MUX_MODE2)   /* etk_ctl.sdmmc3_cmd */ >;
  };

arch/arm/boot/dts/logicpd-torpedo-som.dtsi line 156

Quoted 6 lines
arch/arm/boot/dts/logicpd-torpedo-som.dtsi +6 -0
+	i2c1_pins: pinmux_i2c1_pins {
+		pinctrl-single,pins = <
+			OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0)        /* i2c1_scl.i2c1_scl */
+			OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0)        /* i2c1_sda.i2c1_sda */
+		>;
+	};

This is being added under &omap3_pmx_core2, but upstream it was added under &omap3_pmx_core. Does that matter?

Ben.

Quoted 6 lines

 };

 #include "twl4030.dtsi"

Signature · 2 lines
Ben Hutchings
Software Developer, Codethink Ltd.
#15 lore raw

Re: [PATCH 4.4 13/36] ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux

Quoted 37 lines · Ben Hutchings
Quoted 36 lines · Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Adam Ford <[email protected]>

commit 74402055a2d3ec998a1ded599e86185a27d9bbf4 upstream.

The pinmuxing was missing for I2C1 which was causing intermittent issues with the PMIC which is connected to I2C1. The bootloader did not quite configure the I2C1 either, so when running at 2.6MHz, it was generating errors at time.

This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz

Fixes 687c27676151 ("ARM: dts: Add minimal support for LogicPD Torpedo

DM3730 devkit")

---
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi |    8 ++++++++
 1 file changed, 8 insertions(+)
arch/arm/boot/dts/logicpd-torpedo-som.dtsi +2 -0
@@ -90,6 +90,8 @@
 };
 
 &i2c1 {
+     pinctrl-names = "default";
+     pinctrl-0 = <&i2c1_pins>;
      clock-frequency = <2600000>;
 
Quoted 14 lines

arch/arm/boot/dts/logicpd-torpedo-som.dtsi line 156

Quoted 11 lines
arch/arm/boot/dts/logicpd-torpedo-som.dtsi +6 -0
      twl: twl@48 {
@@ -146,6 +148,12 @@
                      OMAP3630_CORE2_IOPAD(0x25da, PIN_INPUT_PULLUP | MUX_MODE2)   /* etk_ctl.sdmmc3_cmd */
              >;
      };
+     i2c1_pins: pinmux_i2c1_pins {
+             pinctrl-single,pins = <
+                     OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0)        /* i2c1_scl.i2c1_scl */
+                     OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0)        /* i2c1_sda.i2c1_sda */
+             >;
+     };

This is being added under &omap3_pmx_core2, but upstream it was added under &omap3_pmx_core. Does that matter?

I would agree with you that it should be under the omap3_pmx_core

I have been trying to get time to run tests on this, but due to a hard drive corruption, I haven't been able to do much for the past several days.

Greg - If I find it doesn't doesn't work as-is, do you want me to submit a patch to you directly, or go through alternative means?

adam

Quoted 13 lines

Ben.

arch/arm/boot/dts/logicpd-torpedo-som.dtsi line 159

Quoted 6 lines
arch/arm/boot/dts/logicpd-torpedo-som.dtsi +0 -0
 };
 
 #include "twl4030.dtsi"

--
Ben Hutchings
Software Developer, Codethink Ltd.

author maintainer
#16 lore raw

Re: [PATCH 4.4 13/36] ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux

Quoted 54 lines · Adam Ford
Quoted 37 lines · Ben Hutchings
Quoted 36 lines · Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Adam Ford <[email protected]>

commit 74402055a2d3ec998a1ded599e86185a27d9bbf4 upstream.

The pinmuxing was missing for I2C1 which was causing intermittent issues with the PMIC which is connected to I2C1. The bootloader did not quite configure the I2C1 either, so when running at 2.6MHz, it was generating errors at time.

This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz

Fixes 687c27676151 ("ARM: dts: Add minimal support for LogicPD Torpedo

DM3730 devkit")

---
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi |    8 ++++++++
 1 file changed, 8 insertions(+)
arch/arm/boot/dts/logicpd-torpedo-som.dtsi +2 -0
@@ -90,6 +90,8 @@
 };
 
 &i2c1 {
+     pinctrl-names = "default";
+     pinctrl-0 = <&i2c1_pins>;
      clock-frequency = <2600000>;
 
Quoted 14 lines

arch/arm/boot/dts/logicpd-torpedo-som.dtsi line 156

Quoted 11 lines
arch/arm/boot/dts/logicpd-torpedo-som.dtsi +6 -0
      twl: twl@48 {
@@ -146,6 +148,12 @@
                      OMAP3630_CORE2_IOPAD(0x25da, PIN_INPUT_PULLUP | MUX_MODE2)   /* etk_ctl.sdmmc3_cmd */
              >;
      };
+     i2c1_pins: pinmux_i2c1_pins {
+             pinctrl-single,pins = <
+                     OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0)        /* i2c1_scl.i2c1_scl */
+                     OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0)        /* i2c1_sda.i2c1_sda */
+             >;
+     };

This is being added under &omap3_pmx_core2, but upstream it was added under &omap3_pmx_core. Does that matter?

Quoted 8 lines

I would agree with you that it should be under the omap3_pmx_core

I have been trying to get time to run tests on this, but due to a hard drive corruption, I haven't been able to do much for the past several days.

Greg - If I find it doesn't doesn't work as-is, do you want me to submit a patch to you directly, or go through alternative means?

Ugh, how about I revert this one, as the current code is wrong, and you just provide a correct backport when you get a chance to create/test it?

thanks,

greg k-h

author maintainer
#17 lore raw

PATCH 14/36 x86/apic/vector: Handle legacy irq data correctly

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Thomas Gleixner <[email protected]>

The backport of upstream commit 45d55e7bac40 ("x86/apic/vector: Fix off by one in error path") missed to fixup the legacy interrupt data which is not longer available upstream.

Handle legacy irq data correctly by clearing the legacy storage to prevent use after free.

Fixes 7fd133539289 ("x86/apic/vector: Fix off by one in error path") - 4.4.y
Fixes c557481a9491 ("x86/apic/vector: Fix off by one in error path") - 4.9.y
---
 arch/x86/kernel/apic/vector.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)
arch/x86/kernel/apic/vector.c +7 -7
@@ -91,8 +91,12 @@ out_data:
 	return NULL;
 }
 
-static void free_apic_chip_data(struct apic_chip_data *data)
+static void free_apic_chip_data(unsigned int virq, struct apic_chip_data *data)
 {
+#ifdef	CONFIG_X86_IO_APIC
+	if (virq  < nr_legacy_irqs())
+		legacy_irq_data[virq] = NULL;
+#endif
 	if (data) {
 		free_cpumask_var(data->domain);
 		free_cpumask_var(data->old_domain);
@@ -316,11 +320,7 @@ static void x86_vector_free_irqs(struct
 			apic_data = irq_data->chip_data;
 			irq_domain_reset_irq_data(irq_data);
 			raw_spin_unlock_irqrestore(&vector_lock, flags);
-			free_apic_chip_data(apic_data);
-#ifdef	CONFIG_X86_IO_APIC
-			if (virq + i < nr_legacy_irqs())
-				legacy_irq_data[virq + i] = NULL;
-#endif
+			free_apic_chip_data(virq + i, apic_data);
 		}
 	}
 }
@@ -361,7 +361,7 @@ static int x86_vector_alloc_irqs(struct
 		err = assign_irq_vector_policy(virq + i, node, data, info);
 		if (err) {
 			irq_data->chip_data = NULL;
-			free_apic_chip_data(data);
+			free_apic_chip_data(virq + i, data);
 			goto error;
 		}
 	}
author maintainer
#18 lore raw

PATCH 15/36 leds: do not overflow sysfs buffer in led_trigger_show

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Nathan Sullivan <[email protected]>

commit 3b9b95363c45365d606ad4bbba16acca75fdf6d3 upstream.

Per the documentation, use scnprintf instead of sprintf to ensure there is never more than PAGE_SIZE bytes of trigger names put into the buffer.

---
 drivers/leds/led-triggers.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)
drivers/leds/led-triggers.c +7 -5
@@ -88,21 +88,23 @@ ssize_t led_trigger_show(struct device *
 	down_read(&led_cdev->trigger_lock);
 
 	if (!led_cdev->trigger)
-		len += sprintf(buf+len, "[none] ");
+		len += scnprintf(buf+len, PAGE_SIZE - len, "[none] ");
 	else
-		len += sprintf(buf+len, "none ");
+		len += scnprintf(buf+len, PAGE_SIZE - len, "none ");
 
 	list_for_each_entry(trig, &trigger_list, next_trig) {
 		if (led_cdev->trigger && !strcmp(led_cdev->trigger->name,
 							trig->name))
-			len += sprintf(buf+len, "[%s] ", trig->name);
+			len += scnprintf(buf+len, PAGE_SIZE - len, "[%s] ",
+					 trig->name);
 		else
-			len += sprintf(buf+len, "%s ", trig->name);
+			len += scnprintf(buf+len, PAGE_SIZE - len, "%s ",
+					 trig->name);
 	}
 	up_read(&led_cdev->trigger_lock);
 	up_read(&triggers_list_lock);
 
-	len += sprintf(len+buf, "\n");
+	len += scnprintf(len+buf, PAGE_SIZE - len, "\n");
 	return len;
 }
 EXPORT_SYMBOL_GPL(led_trigger_show);
author maintainer
#19 lore raw

PATCH 16/36 x86/spectre: Fix an error message

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Carpenter <[email protected]>

commit 9de29eac8d2189424d81c0d840cd0469aa3d41c8 upstream.

If i = ARRAY_SIZE(mitigation_options) then we accidentally print garbage from one space beyond the end of the mitigation_options[] array.

Cc Andy Lutomirski <[email protected]>
Cc Borislav Petkov <[email protected]>
Cc David Woodhouse <[email protected]>
Cc Greg Kroah-Hartman <[email protected]>
Cc KarimAllah Ahmed <[email protected]>
Cc Linus Torvalds <[email protected]>
Cc Peter Zijlstra <[email protected]>
Cc Thomas Gleixner <[email protected]>
Fixes 9005c6834c0f ("x86/spectre: Simplify spectre_v2 command line parsing")
Cc Ben Hutchings <[email protected]>
---
 arch/x86/kernel/cpu/bugs.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
arch/x86/kernel/cpu/bugs.c +1 -2
@@ -175,8 +175,7 @@ static enum spectre_v2_mitigation_cmd __
 		}
 
 		if (i >= ARRAY_SIZE(mitigation_options)) {
-			pr_err("unknown option (%s). Switching to AUTO select\n",
-			       mitigation_options[i].option);
+			pr_err("unknown option (%s). Switching to AUTO select\n", arg);
 			return SPECTRE_V2_CMD_AUTO;
 		}
 	}
author maintainer
#20 lore raw

PATCH 17/36 Revert "led: core: Fix brightness setting when setting delay_off=0"

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Ben Hutchings <[email protected]>

This reverts commit 20ac8f72514b3af8b62c520d55656ded865eff00, which was commit 2b83ff96f51d0b039c4561b9f95c824d7bddb85c upstream. The bug that it should fix was only introduced in Linux 4.7, and in 4.4 it causes a regression.

---
 drivers/leds/led-core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/leds/led-core.c +1 -1
@@ -149,7 +149,7 @@ void led_blink_set(struct led_classdev *
 		   unsigned long *delay_on,
 		   unsigned long *delay_off)
 {
-	led_stop_software_blink(led_cdev);
+	del_timer_sync(&led_cdev->blink_timer);
 
 	led_cdev->flags &= ~LED_BLINK_ONESHOT;
 	led_cdev->flags &= ~LED_BLINK_ONESHOT_STOP;
author maintainer
#21 lore raw

PATCH 18/36 bridge: check brport attr show in brport_show

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Xin Long <[email protected]>

[ Upstream commit 1b12580af1d0677c3c3a19e35bfe5d59b03f737f ]

Now br_sysfs_if file flush doesn't have attr show. To read it will cause kernel panic after users chmod u+r this file.

Xiong found this issue when running the commands:

ip link add br0 type bridge
ip link add type veth
ip link set veth0 master br0
chmod u+r /sys/devices/virtual/net/veth0/brport/flush timeout 3 cat /sys/devices/virtual/net/veth0/brport/flush

kernel crashed with NULL a pointer dereference call trace.

This patch is to fix it by return -EINVAL when brport_attr->show is null, just the same as the check for brport_attr->store in brport_store().

Fixes 9cf637473c85 ("bridge: add sysfs hook to flush forwarding table")
---
 net/bridge/br_sysfs_if.c |    3 +++
 1 file changed, 3 insertions(+)
net/bridge/br_sysfs_if.c +3 -0
@@ -229,6 +229,9 @@ static ssize_t brport_show(struct kobjec
 	struct brport_attribute *brport_attr = to_brport_attr(attr);
 	struct net_bridge_port *p = to_brport(kobj);
 
+	if (!brport_attr->show)
+		return -EINVAL;
+
 	return brport_attr->show(p, buf);
 }
 
author maintainer
#22 lore raw

PATCH 19/36 fib_semantics: Dont match route with mismatching tclassid

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Stefano Brivio <[email protected]>

[ Upstream commit a8c6db1dfd1b1d18359241372bb204054f2c3174 ]

In fib_nh_match(), if output interface or gateway are passed in the FIB configuration, we don't have to check next hops of multipath routes to conclude whether we have a match or not.

However, we might still have routes with different realms matching the same output interface and gateway configuration, and this needs to cause the match to fail. Otherwise the first route inserted in the FIB will match, regardless of the realms:

 # ip route add 1.1.1.1 dev eth0 table 1234 realms 1/2
 # ip route append 1.1.1.1 dev eth0 table 1234 realms 3/4
 # ip route list table 1234
 1.1.1.1 dev eth0 scope link realms 1/2
 1.1.1.1 dev eth0 scope link realms 3/4
 # ip route del 1.1.1.1 dev ens3 table 1234 realms 3/4
 # ip route list table 1234
 1.1.1.1 dev ens3 scope link realms 3/4

whereas route with realms 3/4 should have been deleted instead.

Explicitly check for fc_flow passed in the FIB configuration (this comes from RTA_FLOW extracted by rtm_to_fib_config()) and fail matching if it differs from nh_tclassid.

The handling of RTA_FLOW for multipath routes later in fib_nh_match() is still needed, as we can have multiple RTA_FLOW attributes that need to be matched against the tclassid of each next hop.

v2: Check that fc_flow is set before discarding the match, so
that the user can still select the first matching rule by not specifying any realm, as suggested by David Ahern.

---
 net/ipv4/fib_semantics.c |    5 +++++
 1 file changed, 5 insertions(+)
net/ipv4/fib_semantics.c +5 -0
@@ -640,6 +640,11 @@ int fib_nh_match(struct fib_config *cfg,
 					    fi->fib_nh, cfg))
 			    return 1;
 		}
+#ifdef CONFIG_IP_ROUTE_CLASSID
+		if (cfg->fc_flow &&
+		    cfg->fc_flow != fi->fib_nh->nh_tclassid)
+			return 1;
+#endif
 		if ((!cfg->fc_oif || cfg->fc_oif == fi->fib_nh->nh_oif) &&
 		    (!cfg->fc_gw  || cfg->fc_gw == fi->fib_nh->nh_gw))
 			return 0;
author maintainer
#23 lore raw

PATCH 20/36 hdlc_ppp: carrier detect ok, dont turn off negotiation

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Denis Du <[email protected]>

[ Upstream commit b6c3bad1ba83af1062a7ff6986d9edc4f3d7fc8e ]

Sometimes when physical lines have a just good noise to make the protocol handshaking fail, but the carrier detect still good. Then after remove of the noise, nobody will trigger this protocol to be start again to cause the link to never come back. The fix is when the carrier is still on, not terminate the protocol handshaking.

---
 drivers/net/wan/hdlc_ppp.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/wan/hdlc_ppp.c +4 -1
@@ -574,7 +574,10 @@ static void ppp_timer(unsigned long arg)
 			ppp_cp_event(proto->dev, proto->pid, TO_GOOD, 0, 0,
 				     0, NULL);
 			proto->restart_counter--;
-		} else
+		} else if (netif_carrier_ok(proto->dev))
+			ppp_cp_event(proto->dev, proto->pid, TO_GOOD, 0, 0,
+				     0, NULL);
+		else
 			ppp_cp_event(proto->dev, proto->pid, TO_BAD, 0, 0,
 				     0, NULL);
 		break;
author maintainer
#24 lore raw

PATCH 21/36 ipv6 sit: work around bogus gcc-8 -Wrestrict warning

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Arnd Bergmann <[email protected]>

[ Upstream commit ca79bec237f5809a7c3c59bd41cd0880aa889966 ]

gcc-8 has a new warning that detects overlapping input and output arguments in memcpy(). It triggers for sit_init_net() calling ipip6_tunnel_clone_6rd(), which is actually correct:

net/ipv6/sit.c: In function 'sit_init_net':
net/ipv6/sit.c:192:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]

The problem here is that the logic detecting the memcpy() arguments finds them to be the same, but the conditional that tests for the input and output of ipip6_tunnel_clone_6rd() to be identical is not a compile-time constant.

We know that netdev_priv(t->dev) is the same as t for a tunnel device, and comparing "dev" directly here lets the compiler figure out as well that 'dev == sitn->fb_tunnel_dev' when called from sit_init_net(), so it no longer warns.

This code is old, so Cc stable to make sure that we don't get the warning for older kernels built with new gcc.

---
 net/ipv6/sit.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv6/sit.c +1 -1
@@ -176,7 +176,7 @@ static void ipip6_tunnel_clone_6rd(struc
 #ifdef CONFIG_IPV6_SIT_6RD
 	struct ip_tunnel *t = netdev_priv(dev);
 
-	if (t->dev == sitn->fb_tunnel_dev) {
+	if (dev == sitn->fb_tunnel_dev) {
 		ipv6_addr_set(&t->ip6rd.prefix, htonl(0x20020000), 0, 0, 0);
 		t->ip6rd.relay_prefix = 0;
 		t->ip6rd.prefixlen = 16;
author maintainer
#25 lore raw

PATCH 22/36 net: fix race on decreasing number of TX queues

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Jakub Kicinski <[email protected]>

[ Upstream commit ac5b70198adc25c73fba28de4f78adcee8f6be0b ]

netif_set_real_num_tx_queues() can be called when netdev is up. That usually happens when user requests change of number of channels/rings with ethtool -L. The procedure for changing the number of queues involves resetting the qdiscs and setting dev->num_tx_queues to the new value. When the new value is lower than the old one, extra care has to be taken to ensure ordering of accesses to the number of queues vs qdisc reset.

Currently the queues are reset before new dev->num_tx_queues is assigned, leaving a window of time where packets can be enqueued onto the queues going down, leading to a likely crash in the drivers, since most drivers don't check if TX skbs are assigned to an active queue.

Fixes e6484930d7c7 ("net: allocate tx queues in register_netdevice")
---
 net/core/dev.c |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)
net/core/dev.c +9 -2
@@ -2183,8 +2183,11 @@ EXPORT_SYMBOL(netif_set_xps_queue);
  */
 int netif_set_real_num_tx_queues(struct net_device *dev, unsigned int txq)
 {
+	bool disabling;
 	int rc;
 
+	disabling = txq < dev->real_num_tx_queues;
+
 	if (txq < 1 || txq > dev->num_tx_queues)
 		return -EINVAL;
 
@@ -2200,15 +2203,19 @@ int netif_set_real_num_tx_queues(struct
 		if (dev->num_tc)
 			netif_setup_tc(dev, txq);
 
-		if (txq < dev->real_num_tx_queues) {
+		dev->real_num_tx_queues = txq;
+
+		if (disabling) {
+			synchronize_net();
 			qdisc_reset_all_tx_gt(dev, txq);
 #ifdef CONFIG_XPS
 			netif_reset_xps_queues_gt(dev, txq);
 #endif
 		}
+	} else {
+		dev->real_num_tx_queues = txq;
 	}
 
-	dev->real_num_tx_queues = txq;
 	return 0;
 }
 EXPORT_SYMBOL(netif_set_real_num_tx_queues);
author maintainer
#26 lore raw

PATCH 23/36 net: ipv4: dont allow setting net.ipv4.route.min_pmtu below 68

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Sabrina Dubroca <[email protected]>

[ Upstream commit c7272c2f1229125f74f22dcdd59de9bbd804f1c8 ]

According to RFC 1191 sections 3 and 4, ICMP frag-needed messages indicating an MTU below 68 should be rejected:

A host MUST never reduce its estimate of the Path MTU below 68 octets.

and (talking about ICMP frag-needed's Next-Hop MTU field):

This field will never contain a value less than 68, since every router "must be able to forward a datagram of 68 octets without fragmentation".

Furthermore, by letting net.ipv4.route.min_pmtu be set to negative values, we can end up with a very large PMTU when (-1) is cast into u32.

Let's also make ip_rt_min_pmtu a u32, since it's only ever compared to unsigned ints.

---
 net/ipv4/route.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
net/ipv4/route.c +6 -2
@@ -126,10 +126,13 @@ static int ip_rt_redirect_silence __read
 static int ip_rt_error_cost __read_mostly	= HZ;
 static int ip_rt_error_burst __read_mostly	= 5 * HZ;
 static int ip_rt_mtu_expires __read_mostly	= 10 * 60 * HZ;
-static int ip_rt_min_pmtu __read_mostly		= 512 + 20 + 20;
+static u32 ip_rt_min_pmtu __read_mostly		= 512 + 20 + 20;
 static int ip_rt_min_advmss __read_mostly	= 256;
 
 static int ip_rt_gc_timeout __read_mostly	= RT_GC_TIMEOUT;
+
+static int ip_min_valid_pmtu __read_mostly	= IPV4_MIN_MTU;
+
 /*
  *	Interface to generic destination cache.
  */
@@ -2765,7 +2768,8 @@ static struct ctl_table ipv4_route_table
 		.data		= &ip_rt_min_pmtu,
 		.maxlen		= sizeof(int),
 		.mode		= 0644,
-		.proc_handler	= proc_dointvec,
+		.proc_handler	= proc_dointvec_minmax,
+		.extra1		= &ip_min_valid_pmtu,
 	},
 	{
 		.procname	= "min_adv_mss",
author maintainer
#27 lore raw

PATCH 24/36 netlink: ensure to loop over all netns in genlmsg_multicast_allns()

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Nicolas Dichtel <[email protected]>

[ Upstream commit cb9f7a9a5c96a773bbc9c70660dc600cfff82f82 ]

Nowadays, nlmsg_multicast() returns only 0 or -ESRCH but this was not the case when commit 134e63756d5f was pushed.
However, there was no reason to stop the loop if a netns does not have listeners.
Returns -ESRCH only if there was no listeners in all netns.

To avoid having the same problem in the future, I didn't take the assumption that nlmsg_multicast() returns only 0 or -ESRCH.

Fixes 134e63756d5f ("genetlink: make netns aware")
CC Johannes Berg <[email protected]>
---
 net/netlink/genetlink.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)
net/netlink/genetlink.c +10 -2
@@ -1118,6 +1118,7 @@ static int genlmsg_mcast(struct sk_buff
 {
 	struct sk_buff *tmp;
 	struct net *net, *prev = NULL;
+	bool delivered = false;
 	int err;
 
 	for_each_net_rcu(net) {
@@ -1129,14 +1130,21 @@ static int genlmsg_mcast(struct sk_buff
 			}
 			err = nlmsg_multicast(prev->genl_sock, tmp,
 					      portid, group, flags);
-			if (err)
+			if (!err)
+				delivered = true;
+			else if (err != -ESRCH)
 				goto error;
 		}
 
 		prev = net;
 	}
 
-	return nlmsg_multicast(prev->genl_sock, skb, portid, group, flags);
+	err = nlmsg_multicast(prev->genl_sock, skb, portid, group, flags);
+	if (!err)
+		delivered = true;
+	else if (err != -ESRCH)
+		goto error;
+	return delivered ? 0 : -ESRCH;
  error:
 	kfree_skb(skb);
 	return err;
#28 lore raw

Re: [PATCH 4.4 24/36] netlink: ensure to loop over all netns in genlmsg_multicast_allns()

Quoted 8 lines · Greg Kroah-Hartman

4.4-stable review patch.  If anyone has any objections, please let me know.

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

From: Nicolas Dichtel <[email protected]>

[ Upstream commit cb9f7a9a5c96a773bbc9c70660dc600cfff82f82 ]

[...]

net/netlink/genetlink.c static int genlmsg_mcast(struct sk_buff · line 1146

Quoted 6 lines
net/netlink/genetlink.c +5 -1
-	return nlmsg_multicast(prev->genl_sock, skb, portid, group, flags);
+	err = nlmsg_multicast(prev->genl_sock, skb, portid, group, flags);
+	if (!err)
+		delivered = true;
+	else if (err != -ESRCH)
+		goto error;

This call to nlmsg_multicast() consumes skb rather than a clone, so we must not free it again here.

Ben.

Quoted 7 lines
net/netlink/genetlink.c +1 -0
+	return delivered ? 0 : -ESRCH;

  error:
  kfree_skb(skb);
  return err;

Signature · 2 lines
Ben Hutchings
Software Developer, Codethink Ltd.
#29 lore raw

Re: [PATCH 4.4 24/36] netlink: ensure to loop over all netns in genlmsg_multicast_allns()

Le 13/03/2018 à 01:04, Ben Hutchings a écrit :

Quoted 10 lines · Greg Kroah-Hartman
Quoted 8 lines

4.4-stable review patch.  If anyone has any objections, please let me know.

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

From: Nicolas Dichtel <[email protected]>

[ Upstream commit cb9f7a9a5c96a773bbc9c70660dc600cfff82f82 ]

[...]

Quoted 9 lines

net/netlink/genetlink.c static int genlmsg_mcast(struct sk_buff · line 1146

Quoted 6 lines
net/netlink/genetlink.c +5 -1
-	return nlmsg_multicast(prev->genl_sock, skb, portid, group, flags);
+	err = nlmsg_multicast(prev->genl_sock, skb, portid, group, flags);
+	if (!err)
+		delivered = true;
+	else if (err != -ESRCH)
+		goto error;

This call to nlmsg_multicast() consumes skb rather than a clone, so we must not free it again here.

Right, good catch.

I will send an update.

Regards,
Nicolas

#30 lore raw

PATCH 1/1 netlink: avoid a double skb free in genlmsg_mcast()

In reply to Ben Hutchings

nlmsg_multicast() consumes always the skb, thus the original skb must be freed only when this function is called with a clone.

Fixes cb9f7a9a5c96 ("netlink: ensure to loop over all netns in genlmsg_multicast_allns()")
---
 net/netlink/genetlink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/netlink/genetlink.c +1 -1
index 6f02499ef007..b9ce82c9440f 100644
@@ -1106,7 +1106,7 @@ static int genlmsg_mcast(struct sk_buff *skb, u32 portid, unsigned long group,
 	if (!err)
 		delivered = true;
 	else if (err != -ESRCH)
-		goto error;
+		return err;
 	return delivered ? 0 : -ESRCH;
  error:
 	kfree_skb(skb);
Signature · 1 line
2.15.1
maintainer
#31 lore raw

Re: [PATCH net] netlink: avoid a double skb free in genlmsg_mcast()

From: Nicolas Dichtel <[email protected]>
Date: Wed, 14 Mar 2018 21:10:23 +0100

Quoted 6 lines

nlmsg_multicast() consumes always the skb, thus the original skb must be freed only when this function is called with a clone.

Fixes cb9f7a9a5c96 ("netlink: ensure to loop over all netns in genlmsg_multicast_allns()")

Yeah these "clone until final send" loops can be tricky to manage.

Good catch, applied and queued up for -stable, thanks.

author maintainer
#32 lore raw

PATCH 25/36 ppp: prevent unregistered channels from connecting to PPP units

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Guillaume Nault <[email protected]>

[ Upstream commit 77f840e3e5f09c6d7d727e85e6e08276dd813d11 ]

PPP units don't hold any reference on the channels connected to it. It is the channel's responsibility to ensure that it disconnects from its unit before being destroyed.
In practice, this is ensured by ppp_unregister_channel() disconnecting the channel from the unit before dropping a reference on the channel.

However, it is possible for an unregistered channel to connect to a PPP
unit: register a channel with ppp_register_net_channel(), attach a /dev/ppp file to it with ioctl(PPPIOCATTCHAN), unregister the channel with ppp_unregister_channel() and finally connect the /dev/ppp file to a PPP unit with ioctl(PPPIOCCONNECT).

Once in this situation, the channel is only held by the /dev/ppp file, which can be released at anytime and free the channel without letting the parent PPP unit know. Then the ppp structure ends up with dangling pointers in its ->channels list.

Prevent this scenario by forbidding unregistered channels from connecting to PPP units. This maintains the code logic by keeping ppp_unregister_channel() responsible from disconnecting the channel if necessary and avoids modification on the reference counting mechanism.

This issue seems to predate git history (successfully reproduced on Linux 2.6.26 and earlier PPP commits are unrelated).

---
 drivers/net/ppp/ppp_generic.c |    9 +++++++++
 1 file changed, 9 insertions(+)
drivers/net/ppp/ppp_generic.c +9 -0
@@ -2952,6 +2952,15 @@ ppp_connect_channel(struct channel *pch,
 		goto outl;
 
 	ppp_lock(ppp);
+	spin_lock_bh(&pch->downl);
+	if (!pch->chan) {
+		/* Don't connect unregistered channels */
+		spin_unlock_bh(&pch->downl);
+		ppp_unlock(ppp);
+		ret = -ENOTCONN;
+		goto outl;
+	}
+	spin_unlock_bh(&pch->downl);
 	if (pch->file.hdrlen > ppp->file.hdrlen)
 		ppp->file.hdrlen = pch->file.hdrlen;
 	hdrlen = pch->file.hdrlen + 2;	/* for protocol bytes */
author maintainer
#33 lore raw

PATCH 26/36 udplite: fix partial checksum initialization

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Alexey Kodanev <[email protected]>

[ Upstream commit 15f35d49c93f4fa9875235e7bf3e3783d2dd7a1b ]

Since UDP-Lite is always using checksum, the following path is triggered when calculating pseudo header for it:

udp4_csum_init() or udp6_csum_init()
skb_checksum_init_zero_check()
__skb_checksum_validate_complete()

The problem can appear if skb->len is less than CHECKSUM_BREAK. In this particular case __skb_checksum_validate_complete() also invokes __skb_checksum_complete(skb). If UDP-Lite is using partial checksum that covers only part of a packet, the function will return bad checksum and the packet will be dropped.

It can be fixed if we skip skb_checksum_init_zero_check() and only set the required pseudo header checksum for UDP-Lite with partial checksum before udp4_csum_init()/udp6_csum_init() functions return.

Fixes ed70fcfcee95 ("net: Call skb_checksum_init in IPv4")
Fixes e4f45b7f40bd ("net: Call skb_checksum_init in IPv6")
---
 include/net/udplite.h   |    1 +
 net/ipv4/udp.c          |    5 +++++
 net/ipv6/ip6_checksum.c |    5 +++++
 3 files changed, 11 insertions(+)
include/net/udplite.h +1 -0
@@ -62,6 +62,7 @@ static inline int udplite_checksum_init(
 		UDP_SKB_CB(skb)->cscov = cscov;
 		if (skb->ip_summed == CHECKSUM_COMPLETE)
 			skb->ip_summed = CHECKSUM_NONE;
+		skb->csum_valid = 0;
         }
 
 	return 0;
net/ipv4/udp.c +5 -0
@@ -1744,6 +1744,11 @@ static inline int udp4_csum_init(struct
 		err = udplite_checksum_init(skb, uh);
 		if (err)
 			return err;
+
+		if (UDP_SKB_CB(skb)->partial_cov) {
+			skb->csum = inet_compute_pseudo(skb, proto);
+			return 0;
+		}
 	}
 
 	return skb_checksum_init_zero_check(skb, proto, uh->check,
net/ipv6/ip6_checksum.c +5 -0
@@ -73,6 +73,11 @@ int udp6_csum_init(struct sk_buff *skb,
 		err = udplite_checksum_init(skb, uh);
 		if (err)
 			return err;
+
+		if (UDP_SKB_CB(skb)->partial_cov) {
+			skb->csum = ip6_compute_pseudo(skb, proto);
+			return 0;
+		}
 	}
 
 	/* To support RFC 6936 (allow zero checksum in UDP/IPV6 for tunnels)
author maintainer
#34 lore raw

PATCH 27/36 sctp: fix dst refcnt leak in sctp_v4_get_dst

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Tommi Rantala <[email protected]>

[ Upstream commit 4a31a6b19f9ddf498c81f5c9b089742b7472a6f8 ]

Fix dst reference count leak in sctp_v4_get_dst() introduced in commit 410f03831 ("sctp: add routing output fallback"):

When walking the address_list, successive ip_route_output_key() calls may return the same rt->dst with the reference incremented on each call.

The code would not decrement the dst refcount when the dst pointer was identical from the previous iteration, causing the dst refcnt leak.

Testcase:
ip netns add TEST
ip netns exec TEST ip link set lo up
ip link add dummy0 type dummy
ip link add dummy1 type dummy
ip link add dummy2 type dummy
ip link set dev dummy0 netns TEST
ip link set dev dummy1 netns TEST
ip link set dev dummy2 netns TEST
ip netns exec TEST ip addr add 192.168.1.1/24 dev dummy0
ip netns exec TEST ip link set dummy0 up
ip netns exec TEST ip addr add 192.168.1.2/24 dev dummy1
ip netns exec TEST ip link set dummy1 up
ip netns exec TEST ip addr add 192.168.1.3/24 dev dummy2
ip netns exec TEST ip link set dummy2 up
ip netns exec TEST sctp_test -H 192.168.1.2 -P 20002 -h 192.168.1.1 -p 20000 -s -B 192.168.1.3 ip netns del TEST

In 4.4 and 4.9 kernels this results to:

  [  354.179591] unregister_netdevice: waiting for lo to become free. Usage count = 1
  [  364.419674] unregister_netdevice: waiting for lo to become free. Usage count = 1
  [  374.663664] unregister_netdevice: waiting for lo to become free. Usage count = 1
  [  384.903717] unregister_netdevice: waiting for lo to become free. Usage count = 1
  [  395.143724] unregister_netdevice: waiting for lo to become free. Usage count = 1
  [  405.383645] unregister_netdevice: waiting for lo to become free. Usage count = 1
  ...
Fixes 410f03831 ("sctp: add routing output fallback")
Fixes 0ca50d12f ("sctp: fix src address selection if using secondary addresses")
---
 net/sctp/protocol.c |   10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)
net/sctp/protocol.c +4 -6
@@ -508,22 +508,20 @@ static void sctp_v4_get_dst(struct sctp_
 		if (IS_ERR(rt))
 			continue;
 
-		if (!dst)
-			dst = &rt->dst;
-
 		/* Ensure the src address belongs to the output
 		 * interface.
 		 */
 		odev = __ip_dev_find(sock_net(sk), laddr->a.v4.sin_addr.s_addr,
 				     false);
 		if (!odev || odev->ifindex != fl4->flowi4_oif) {
-			if (&rt->dst != dst)
+			if (!dst)
+				dst = &rt->dst;
+			else
 				dst_release(&rt->dst);
 			continue;
 		}
 
-		if (dst != &rt->dst)
-			dst_release(dst);
+		dst_release(dst);
 		dst = &rt->dst;
 		break;
 	}
author maintainer
#35 lore raw

PATCH 28/36 sctp: fix dst refcnt leak in sctp_v6_get_dst()

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Alexey Kodanev <[email protected]>

[ Upstream commit 957d761cf91cdbb175ad7d8f5472336a4d54dbf2 ]

When going through the bind address list in sctp_v6_get_dst() and the previously found address is better ('matchlen > bmatchlen'), the code continues to the next iteration without releasing currently held destination.

Fix it by releasing 'bdst' before continue to the next iteration, and instead of introducing one more '!IS_ERR(bdst)' check for dst_release(), move the already existed one right after ip6_dst_lookup_flow(), i.e. we shouldn't proceed further if we get an error for the route lookup.

Fixes dbc2b5e9a09e ("sctp: fix src address selection if using secondary addresses for ipv6")
---
 net/sctp/ipv6.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)
net/sctp/ipv6.c +7 -3
@@ -323,8 +323,10 @@ static void sctp_v6_get_dst(struct sctp_
 		final_p = fl6_update_dst(fl6, rcu_dereference(np->opt), &final);
 		bdst = ip6_dst_lookup_flow(sk, fl6, final_p);
 
-		if (!IS_ERR(bdst) &&
-		    ipv6_chk_addr(dev_net(bdst->dev),
+		if (IS_ERR(bdst))
+			continue;
+
+		if (ipv6_chk_addr(dev_net(bdst->dev),
 				  &laddr->a.v6.sin6_addr, bdst->dev, 1)) {
 			if (!IS_ERR_OR_NULL(dst))
 				dst_release(dst);
@@ -333,8 +335,10 @@ static void sctp_v6_get_dst(struct sctp_
 		}
 
 		bmatchlen = sctp_v6_addr_match_len(daddr, &laddr->a);
-		if (matchlen > bmatchlen)
+		if (matchlen > bmatchlen) {
+			dst_release(bdst);
 			continue;
+		}
 
 		if (!IS_ERR_OR_NULL(dst))
 			dst_release(dst);
author maintainer
#36 lore raw

PATCH 29/36 s390/qeth: fix SETIP command handling

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Julian Wiedmann <[email protected]>

[ Upstream commit 1c5b2216fbb973a9410e0b06389740b5c1289171 ]

send_control_data() applies some special handling to SETIP v4 IPA commands. But current code parses *all* command types for the SETIP command code. Limit the command code check to IPA commands.

Fixes 5b54e16f1a54 ("qeth: do not spin for SETIP ip assist command")
---
 drivers/s390/net/qeth_core.h      |    5 +++++
 drivers/s390/net/qeth_core_main.c |   14 ++++++++------
 2 files changed, 13 insertions(+), 6 deletions(-)
drivers/s390/net/qeth_core.h +5 -0
@@ -591,6 +591,11 @@ struct qeth_cmd_buffer {
 	void (*callback) (struct qeth_channel *, struct qeth_cmd_buffer *);
 };
 
+static inline struct qeth_ipa_cmd *__ipa_cmd(struct qeth_cmd_buffer *iob)
+{
+	return (struct qeth_ipa_cmd *)(iob->data + IPA_PDU_HEADER_SIZE);
+}
+
 /**
  * definition of a qeth channel, used for read and write
  */
drivers/s390/net/qeth_core_main.c +8 -6
@@ -2054,7 +2054,7 @@ int qeth_send_control_data(struct qeth_c
 	unsigned long flags;
 	struct qeth_reply *reply = NULL;
 	unsigned long timeout, event_timeout;
-	struct qeth_ipa_cmd *cmd;
+	struct qeth_ipa_cmd *cmd = NULL;
 
 	QETH_CARD_TEXT(card, 2, "sendctl");
 
@@ -2081,10 +2081,13 @@ int qeth_send_control_data(struct qeth_c
 	while (atomic_cmpxchg(&card->write.irq_pending, 0, 1)) ;
 	qeth_prepare_control_data(card, len, iob);
 
-	if (IS_IPA(iob->data))
+	if (IS_IPA(iob->data)) {
+		cmd = __ipa_cmd(iob);
 		event_timeout = QETH_IPA_TIMEOUT;
-	else
+	} else {
 		event_timeout = QETH_TIMEOUT;
+	}
+
 	timeout = jiffies + event_timeout;
 
 	QETH_CARD_TEXT(card, 6, "noirqpnd");
@@ -2109,9 +2112,8 @@ int qeth_send_control_data(struct qeth_c
 
 	/* we have only one long running ipassist, since we can ensure
 	   process context of this command we can sleep */
-	cmd = (struct qeth_ipa_cmd *)(iob->data+IPA_PDU_HEADER_SIZE);
-	if ((cmd->hdr.command == IPA_CMD_SETIP) &&
-	    (cmd->hdr.prot_version == QETH_PROT_IPV4)) {
+	if (cmd && cmd->hdr.command == IPA_CMD_SETIP &&
+	    cmd->hdr.prot_version == QETH_PROT_IPV4) {
 		if (!wait_event_timeout(reply->wait_q,
 		    atomic_read(&reply->received), event_timeout))
 			goto time_err;
author maintainer
#37 lore raw

PATCH 30/36 s390/qeth: fix IPA command submission race

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Julian Wiedmann <[email protected]>

[ Upstream commit d22ffb5a712f9211ffd104c38fc17cbfb1b5e2b0 ]

If multiple IPA commands are build & sent out concurrently, fill_ipacmd_header() may assign a seqno value to a command that's different from what send_control_data() later assigns to this command's reply.
This is due to other commands passing through send_control_data(), and incrementing card->seqno.ipa along the way.

So one IPA command has no reply that's waiting for its seqno, while some other IPA command has multiple reply objects waiting for it. Only one of those waiting replies wins, and the other(s) times out and triggers a recovery via send_ipa_cmd().

Fix this by making sure that the same seqno value is assigned to a command and its reply object.
Do so immediately before submitting the command & while holding the irq_pending "lock", to produce nicely ascending seqnos.

As a side effect, *all* IPA commands now use a reply object that's waiting for its actual seqno. Previously, early IPA commands that were submitted while the card was still DOWN used the "catch-all" IDX seqno.

---
 drivers/s390/net/qeth_core_main.c |   19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)
drivers/s390/net/qeth_core_main.c +10 -9
@@ -2068,25 +2068,26 @@ int qeth_send_control_data(struct qeth_c
 	}
 	reply->callback = reply_cb;
 	reply->param = reply_param;
-	if (card->state == CARD_STATE_DOWN)
-		reply->seqno = QETH_IDX_COMMAND_SEQNO;
-	else
-		reply->seqno = card->seqno.ipa++;
+
 	init_waitqueue_head(&reply->wait_q);
-	spin_lock_irqsave(&card->lock, flags);
-	list_add_tail(&reply->list, &card->cmd_waiter_list);
-	spin_unlock_irqrestore(&card->lock, flags);
 	QETH_DBF_HEX(CTRL, 2, iob->data, QETH_DBF_CTRL_LEN);
 
 	while (atomic_cmpxchg(&card->write.irq_pending, 0, 1)) ;
-	qeth_prepare_control_data(card, len, iob);
 
 	if (IS_IPA(iob->data)) {
 		cmd = __ipa_cmd(iob);
+		cmd->hdr.seqno = card->seqno.ipa++;
+		reply->seqno = cmd->hdr.seqno;
 		event_timeout = QETH_IPA_TIMEOUT;
 	} else {
+		reply->seqno = QETH_IDX_COMMAND_SEQNO;
 		event_timeout = QETH_TIMEOUT;
 	}
+	qeth_prepare_control_data(card, len, iob);
+
+	spin_lock_irqsave(&card->lock, flags);
+	list_add_tail(&reply->list, &card->cmd_waiter_list);
+	spin_unlock_irqrestore(&card->lock, flags);
 
 	timeout = jiffies + event_timeout;
 
@@ -2879,7 +2880,7 @@ static void qeth_fill_ipacmd_header(stru
 	memset(cmd, 0, sizeof(struct qeth_ipa_cmd));
 	cmd->hdr.command = command;
 	cmd->hdr.initiator = IPA_CMD_INITIATOR_HOST;
-	cmd->hdr.seqno = card->seqno.ipa;
+	/* cmd->hdr.seqno is set by qeth_send_control_data() */
 	cmd->hdr.adapter_type = qeth_get_ipa_adp_type(card->info.link_type);
 	cmd->hdr.rel_adapter_no = (__u8) card->info.portno;
 	if (card->options.layer2)
author maintainer
#38 lore raw

PATCH 31/36 sctp: verify size of a new chunk in _sctp_make_chunk()

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Alexey Kodanev <[email protected]>

[ Upstream commit 07f2c7ab6f8d0a7e7c5764c4e6cc9c52951b9d9c ]

When SCTP makes INIT or INIT_ACK packet the total chunk length can exceed SCTP_MAX_CHUNK_LEN which leads to kernel panic when transmitting these packets, e.g. the crash on sending INIT_ACK:

[  597.804948] skbuff: skb_over_panic: text:00000000ffae06e4 len:120168
               put:120156 head:000000007aa47635 data:00000000d991c2de
               tail:0x1d640 end:0xfec0 dev:<NULL>
...
[  597.976970] ------------[ cut here ]------------
[  598.033408] kernel BUG at net/core/skbuff.c:104!
[  600.314841] Call Trace:
[  600.345829]  <IRQ>
[  600.371639]  ? sctp_packet_transmit+0x2095/0x26d0 [sctp]
[  600.436934]  skb_put+0x16c/0x200
[  600.477295]  sctp_packet_transmit+0x2095/0x26d0 [sctp]
[  600.540630]  ? sctp_packet_config+0x890/0x890 [sctp]
[  600.601781]  ? __sctp_packet_append_chunk+0x3b4/0xd00 [sctp]
[  600.671356]  ? sctp_cmp_addr_exact+0x3f/0x90 [sctp]
[  600.731482]  sctp_outq_flush+0x663/0x30d0 [sctp]
[  600.788565]  ? sctp_make_init+0xbf0/0xbf0 [sctp]
[  600.845555]  ? sctp_check_transmitted+0x18f0/0x18f0 [sctp]
[  600.912945]  ? sctp_outq_tail+0x631/0x9d0 [sctp]
[  600.969936]  sctp_cmd_interpreter.isra.22+0x3be1/0x5cb0 [sctp]
[  601.041593]  ? sctp_sf_do_5_1B_init+0x85f/0xc30 [sctp]
[  601.104837]  ? sctp_generate_t1_cookie_event+0x20/0x20 [sctp]
[  601.175436]  ? sctp_eat_data+0x1710/0x1710 [sctp]
[  601.233575]  sctp_do_sm+0x182/0x560 [sctp]
[  601.284328]  ? sctp_has_association+0x70/0x70 [sctp]
[  601.345586]  ? sctp_rcv+0xef4/0x32f0 [sctp]
[  601.397478]  ? sctp6_rcv+0xa/0x20 [sctp]

...

Here the chunk size for INIT_ACK packet becomes too big, mostly because of the state cookie (INIT packet has large size with many address parameters), plus additional server parameters.

Later this chunk causes the panic in skb_put_data():

  skb_packet_transmit()
      sctp_packet_pack()
          skb_put_data(nskb, chunk->skb->data, chunk->skb->len);

'nskb' (head skb) was previously allocated with packet->size from u16 'chunk->chunk_hdr->length'.

As suggested by Marcelo we should check the chunk's length in _sctp_make_chunk() before trying to allocate skb for it and discard a chunk if its size bigger than SCTP_MAX_CHUNK_LEN.

---
 net/sctp/sm_make_chunk.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
net/sctp/sm_make_chunk.c +6 -2
@@ -1367,10 +1367,14 @@ static struct sctp_chunk *_sctp_make_chu
 	sctp_chunkhdr_t *chunk_hdr;
 	struct sk_buff *skb;
 	struct sock *sk;
+	int chunklen;
+
+	chunklen = sizeof(*chunk_hdr) + paylen;
+	if (chunklen > SCTP_MAX_CHUNK_LEN)
+		goto nodata;
 
 	/* No need to allocate LL here, as this is only a chunk. */
-	skb = alloc_skb(WORD_ROUND(sizeof(sctp_chunkhdr_t) + paylen),
-			GFP_ATOMIC);
+	skb = alloc_skb(chunklen, GFP_ATOMIC);
 	if (!skb)
 		goto nodata;
 
#39 lore raw

Re: [PATCH 4.4 31/36] sctp: verify size of a new chunk in _sctp_make_chunk()

Quoted 70 lines · Greg Kroah-Hartman

4.4-stable review patch.  If anyone has any objections, please let me know.

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

From: Alexey Kodanev <[email protected]>

[ Upstream commit 07f2c7ab6f8d0a7e7c5764c4e6cc9c52951b9d9c ]

When SCTP makes INIT or INIT_ACK packet the total chunk length can exceed SCTP_MAX_CHUNK_LEN which leads to kernel panic when transmitting these packets, e.g. the crash on sending INIT_ACK:

[  597.804948] skbuff: skb_over_panic: text:00000000ffae06e4 len:120168 put:120156 head:000000007aa47635 data:00000000d991c2de tail:0x1d640 end:0xfec0 dev:<NULL>
...
[  597.976970] ------------[ cut here ]------------
[  598.033408] kernel BUG at net/core/skbuff.c:104!
[  600.314841] Call Trace:
[  600.345829]  <IRQ>
[  600.371639]  ? sctp_packet_transmit+0x2095/0x26d0 [sctp] [  600.436934]  skb_put+0x16c/0x200
[  600.477295]  sctp_packet_transmit+0x2095/0x26d0 [sctp]
[  600.540630]  ? sctp_packet_config+0x890/0x890 [sctp]
[  600.601781]  ? __sctp_packet_append_chunk+0x3b4/0xd00 [sctp] [  600.671356]  ? sctp_cmp_addr_exact+0x3f/0x90 [sctp]
[  600.731482]  sctp_outq_flush+0x663/0x30d0 [sctp]
[  600.788565]  ? sctp_make_init+0xbf0/0xbf0 [sctp]
[  600.845555]  ? sctp_check_transmitted+0x18f0/0x18f0 [sctp] [  600.912945]  ? sctp_outq_tail+0x631/0x9d0 [sctp]
[  600.969936]  sctp_cmd_interpreter.isra.22+0x3be1/0x5cb0 [sctp] [  601.041593]  ? sctp_sf_do_5_1B_init+0x85f/0xc30 [sctp]
[  601.104837]  ? sctp_generate_t1_cookie_event+0x20/0x20 [sctp] [  601.175436]  ? sctp_eat_data+0x1710/0x1710 [sctp]
[  601.233575]  sctp_do_sm+0x182/0x560 [sctp]
[  601.284328]  ? sctp_has_association+0x70/0x70 [sctp]
[  601.345586]  ? sctp_rcv+0xef4/0x32f0 [sctp]
[  601.397478]  ? sctp6_rcv+0xa/0x20 [sctp]
...

Here the chunk size for INIT_ACK packet becomes too big, mostly because of the state cookie (INIT packet has large size with many address parameters), plus additional server parameters.

Later this chunk causes the panic in skb_put_data():

  skb_packet_transmit()
      sctp_packet_pack()
          skb_put_data(nskb, chunk->skb->data, chunk->skb->len);

'nskb' (head skb) was previously allocated with packet->size from u16 'chunk->chunk_hdr->length'.

As suggested by Marcelo we should check the chunk's length in _sctp_make_chunk() before trying to allocate skb for it and discard a chunk if its size bigger than SCTP_MAX_CHUNK_LEN.

Quoted 5 lines

---
 net/sctp/sm_make_chunk.c |    8 ++++++--

 1 file changed, 6 insertions(+), 2 deletions(-)

net/sctp/sm_make_chunk.c static struct sctp_chunk *_sctp_make_chu · line 1372

Quoted 6 lines
net/sctp/sm_make_chunk.c +3 -0
@@ -1367,10 +1367,14 @@ static struct sctp_chunk *_sctp_make_chu
  	sctp_chunkhdr_t *chunk_hdr;
  	struct sk_buff *skb;
  	struct sock *sk;
+	int chunklen;
+
+	chunklen = sizeof(*chunk_hdr) + paylen;

I think this length still needs to be rounded up (with WORD_ROUND here, instead of SCTP_PAD4 upstream).

Ben.

Quoted 13 lines
net/sctp/sm_make_chunk.c +2 -0
+	if (chunklen > SCTP_MAX_CHUNK_LEN)
+		goto nodata;


  /* No need to allocate LL here, as this is only a chunk. */

net/sctp/sm_make_chunk.c +1 -2
-	skb = alloc_skb(WORD_ROUND(sizeof(sctp_chunkhdr_t) + paylen),
-			GFP_ATOMIC);
+	skb = alloc_skb(chunklen, GFP_ATOMIC);

  if (!skb)
  goto nodata;

Signature · 2 lines
Ben Hutchings
Software Developer, Codethink Ltd.
author maintainer
#40 lore raw

Re: [PATCH 4.4 31/36] sctp: verify size of a new chunk in _sctp_make_chunk()

Quoted 68 lines · Ben Hutchings
Quoted 67 lines · Greg Kroah-Hartman

4.4-stable review patch.��If anyone has any objections, please let me know.

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

From: Alexey Kodanev <[email protected]>

[ Upstream commit 07f2c7ab6f8d0a7e7c5764c4e6cc9c52951b9d9c ]

When SCTP makes INIT or INIT_ACK packet the total chunk length can exceed SCTP_MAX_CHUNK_LEN which leads to kernel panic when transmitting these packets, e.g. the crash on sending INIT_ACK:

[��597.804948] skbuff: skb_over_panic: text:00000000ffae06e4 len:120168 ���������������put:120156 head:000000007aa47635 data:00000000d991c2de ���������������tail:0x1d640 end:0xfec0 dev:<NULL>
...
[��597.976970] ------------[ cut here ]------------
[��598.033408] kernel BUG at net/core/skbuff.c:104!
[��600.314841] Call Trace:
[��600.345829]��<IRQ>
[��600.371639]��? sctp_packet_transmit+0x2095/0x26d0 [sctp] [��600.436934]��skb_put+0x16c/0x200 [��600.477295]��sctp_packet_transmit+0x2095/0x26d0 [sctp] [��600.540630]��? sctp_packet_config+0x890/0x890 [sctp] [��600.601781]��? __sctp_packet_append_chunk+0x3b4/0xd00 [sctp] [��600.671356]��? sctp_cmp_addr_exact+0x3f/0x90 [sctp] [��600.731482]��sctp_outq_flush+0x663/0x30d0 [sctp] [��600.788565]��? sctp_make_init+0xbf0/0xbf0 [sctp] [��600.845555]��? sctp_check_transmitted+0x18f0/0x18f0 [sctp] [��600.912945]��? sctp_outq_tail+0x631/0x9d0 [sctp] [��600.969936]��sctp_cmd_interpreter.isra.22+0x3be1/0x5cb0 [sctp] [��601.041593]��? sctp_sf_do_5_1B_init+0x85f/0xc30 [sctp] [��601.104837]��? sctp_generate_t1_cookie_event+0x20/0x20 [sctp] [��601.175436]��? sctp_eat_data+0x1710/0x1710 [sctp] [��601.233575]��sctp_do_sm+0x182/0x560 [sctp]
[��601.284328]��? sctp_has_association+0x70/0x70 [sctp] [��601.345586]��? sctp_rcv+0xef4/0x32f0 [sctp]
[��601.397478]��? sctp6_rcv+0xa/0x20 [sctp]
...

Here the chunk size for INIT_ACK packet becomes too big, mostly because of the state cookie (INIT packet has large size with many address parameters), plus additional server parameters.

Later this chunk causes the panic in skb_put_data():

� skb_packet_transmit()
������sctp_packet_pack() ����������skb_put_data(nskb, chunk->skb->data, chunk->skb->len);

'nskb' (head skb) was previously allocated with packet->size from u16 'chunk->chunk_hdr->length'.

As suggested by Marcelo we should check the chunk's length in _sctp_make_chunk() before trying to allocate skb for it and discard a chunk if its size bigger than SCTP_MAX_CHUNK_LEN.

Quoted 5 lines

---
�net/sctp/sm_make_chunk.c |����8 ++++++-- �1 file changed, 6 insertions(+), 2 deletions(-)

Quoted 12 lines

net/sctp/sm_make_chunk.c static struct sctp_chunk *_sctp_make_chu · line 1372

Quoted 9 lines
net/sctp/sm_make_chunk.c +3 -0
@@ -1367,10 +1367,14 @@ static struct sctp_chunk *_sctp_make_chu
 �	sctp_chunkhdr_t *chunk_hdr;
 �	struct sk_buff *skb;
 �	struct sock *sk;
+	int chunklen;
+
+	chunklen = sizeof(*chunk_hdr) + paylen;

I think this length still needs to be rounded up (with WORD_ROUND here, instead of SCTP_PAD4 upstream).

Ah, good point, how's this patch:

net/sctp/sm_make_chunk.c +1 -1
index 4ca31e052dd8..509e9426a056 100644
@@ -1369,7 +1369,7 @@ static struct sctp_chunk *_sctp_make_chunk(const struct sctp_association *asoc,
 	struct sock *sk;
 	int chunklen;
 
-	chunklen = sizeof(*chunk_hdr) + paylen;
+	chunklen = WORD_ROUND(sizeof(*chunk_hdr) + paylen);
 	if (chunklen > SCTP_MAX_CHUNK_LEN)
 		goto nodata;
 
#41 lore raw

Re: [PATCH 4.4 31/36] sctp: verify size of a new chunk in _sctp_make_chunk()

Quoted 87 lines · Greg Kroah-Hartman
Quoted 72 lines · Ben Hutchings
Quoted 71 lines · Greg Kroah-Hartman

4.4-stable review patch.  If anyone has any objections, please let me know.

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

From: Alexey Kodanev <[email protected]>

[ Upstream commit 07f2c7ab6f8d0a7e7c5764c4e6cc9c52951b9d9c ]

When SCTP makes INIT or INIT_ACK packet the total chunk length can exceed SCTP_MAX_CHUNK_LEN which leads to kernel panic when transmitting these packets, e.g. the crash on sending INIT_ACK:

[  597.804948] skbuff: skb_over_panic: text:00000000ffae06e4 len:120168
               put:120156 head:000000007aa47635 data:00000000d991c2de
               tail:0x1d640 end:0xfec0 dev:<NULL>
...
[  597.976970] ------------[ cut here ]------------
[  598.033408] kernel BUG at net/core/skbuff.c:104!
[  600.314841] Call Trace:
[  600.345829]  <IRQ>
[  600.371639]  ? sctp_packet_transmit+0x2095/0x26d0 [sctp] [  600.436934]  skb_put+0x16c/0x200
[  600.477295]  sctp_packet_transmit+0x2095/0x26d0 [sctp] [  600.540630]  ? sctp_packet_config+0x890/0x890 [sctp] [  600.601781]  ? __sctp_packet_append_chunk+0x3b4/0xd00 [sctp] [  600.671356]  ? sctp_cmp_addr_exact+0x3f/0x90 [sctp] [  600.731482]  sctp_outq_flush+0x663/0x30d0 [sctp]
[  600.788565]  ? sctp_make_init+0xbf0/0xbf0 [sctp]
[  600.845555]  ? sctp_check_transmitted+0x18f0/0x18f0 [sctp] [  600.912945]  ? sctp_outq_tail+0x631/0x9d0 [sctp]
[  600.969936]  sctp_cmd_interpreter.isra.22+0x3be1/0x5cb0 [sctp] [  601.041593]  ? sctp_sf_do_5_1B_init+0x85f/0xc30 [sctp] [  601.104837]  ? sctp_generate_t1_cookie_event+0x20/0x20 [sctp] [  601.175436]  ? sctp_eat_data+0x1710/0x1710 [sctp]
[  601.233575]  sctp_do_sm+0x182/0x560 [sctp]
[  601.284328]  ? sctp_has_association+0x70/0x70 [sctp] [  601.345586]  ? sctp_rcv+0xef4/0x32f0 [sctp]
[  601.397478]  ? sctp6_rcv+0xa/0x20 [sctp]
...

Here the chunk size for INIT_ACK packet becomes too big, mostly because of the state cookie (INIT packet has large size with many address parameters), plus additional server parameters.

Later this chunk causes the panic in skb_put_data():

  skb_packet_transmit()
      sctp_packet_pack()
          skb_put_data(nskb, chunk->skb->data, chunk->skb->len);

'nskb' (head skb) was previously allocated with packet->size from u16 'chunk->chunk_hdr->length'.

As suggested by Marcelo we should check the chunk's length in _sctp_make_chunk() before trying to allocate skb for it and discard a chunk if its size bigger than SCTP_MAX_CHUNK_LEN.

Quoted 5 lines

---
 net/sctp/sm_make_chunk.c |    8 ++++++--

 1 file changed, 6 insertions(+), 2 deletions(-)
Quoted 13 lines

net/sctp/sm_make_chunk.c static struct sctp_chunk *_sctp_make_chu · line 1372

Quoted 9 lines
net/sctp/sm_make_chunk.c +3 -0
@@ -1367,10 +1367,14 @@ static struct sctp_chunk *_sctp_make_chu
  	sctp_chunkhdr_t *chunk_hdr;
  	struct sk_buff *skb;
  	struct sock *sk;
+	int chunklen;
+
+	chunklen = sizeof(*chunk_hdr) + paylen;

I think this length still needs to be rounded up (with WORD_ROUND here,
instead of SCTP_PAD4 upstream).

Quoted 1 line

Ah, good point, how's this patch:

LGTM.

Ben.

Quoted 15 lines
net/sctp/sm_make_chunk.c +0 -0
index 4ca31e052dd8..509e9426a056 100644
@@ -1369,7 +1369,7 @@ static struct sctp_chunk
 *_sctp_make_chunk(const struct sctp_association *asoc,
  	struct sock *sk;
  	int chunklen;

net/sctp/sm_make_chunk.c +1 -1
-	chunklen = sizeof(*chunk_hdr) + paylen;
+	chunklen = WORD_ROUND(sizeof(*chunk_hdr) + paylen);

  if (chunklen > SCTP_MAX_CHUNK_LEN)
  goto nodata;

Signature · 2 lines
Ben Hutchings
Software Developer, Codethink Ltd.
author maintainer Applied
#42 lore raw

Patch "fixup: sctp: verify size of a new chunk in _sctp_make_chunk()" has been added to the 3.18-stable tree

In reply to Greg Kroah-Hartman

This is a note to let you know that I've just added the patch titled

fixup: sctp: verify size of a new chunk in _sctp_make_chunk()

to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
fixup-sctp-verify-size-of-a-new-chunk-in-_sctp_make_chunk.patch
and it can be found in the queue-3.18 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From [email protected] Fri Mar 16 14:27:34 2018

From: Greg Kroah-Hartman <[email protected]>
Date: Tue, 13 Mar 2018 10:56:00 +0100
Subject: fixup: sctp: verify size of a new chunk in _sctp_make_chunk()
To: Ben Hutchings <[email protected]>
Cc: [email protected], [email protected], Alexey Kodanev <[email protected]>, Marcelo Ricardo Leitner <[email protected]>, Neil Horman <[email protected]>, "David S. Miller" <[email protected]>
Message-ID: <[email protected]>
Content-Disposition: inline

From: Greg Kroah-Hartman <[email protected]>

Quoted 6 lines · Ben

Review

Quoted 3 lines
(quoted diff) +3 -0
+	int chunklen;
+
+	chunklen = sizeof(*chunk_hdr) + paylen;

I think this length still needs to be rounded up (with WORD_ROUND here, instead of SCTP_PAD4 upstream).

So here's a fix for this problem.

---
 net/sctp/sm_make_chunk.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/sctp/sm_make_chunk.c +1 -1
@@ -1369,7 +1369,7 @@ static struct sctp_chunk *_sctp_make_chu
 	struct sock *sk;
 	int chunklen;
 
-	chunklen = sizeof(*chunk_hdr) + paylen;
+	chunklen = WORD_ROUND(sizeof(*chunk_hdr) + paylen);
 	if (chunklen > SCTP_MAX_CHUNK_LEN)
 		goto nodata;
 

Patches currently in stable-queue which might be from [email protected] are

queue-3.18/scsi-qla2xxx-fix-null-pointer-crash-due-to-active-timer-for-abts.patch queue-3.18/scripts-recordmcount-break-hardlinks.patch queue-3.18/alsa-seq-don-t-allow-resizing-pool-in-use.patch queue-3.18/serial-sh-sci-prevent-lockup-on-full-tty-buffers.patch queue-3.18/serial-8250_pci-add-brainboxes-uc-260-4-port-serial-device.patch queue-3.18/usb-usbmon-read-text-within-supplied-buffer-size.patch queue-3.18/x86-mce-serialize-sysfs-changes.patch queue-3.18/netfilter-idletimer-be-syzkaller-friendly.patch queue-3.18/usb-quirks-add-control-message-delay-for-1b1c-1b20.patch queue-3.18/x86-module-detect-and-skip-invalid-relocations.patch queue-3.18/ubi-fix-race-condition-between-ubi-volume-creation-and-udev.patch queue-3.18/netfilter-ipv6-fix-use-after-free-write-in-nf_nat_ipv6_manip_pkt.patch queue-3.18/mips-bmips-do-not-mask-ipis-during-suspend.patch queue-3.18/fixup-sctp-verify-size-of-a-new-chunk-in-_sctp_make_chunk.patch queue-3.18/netfilter-ebtables-config_compat-don-t-trust-userland-offsets.patch queue-3.18/alsa-seq-more-protection-for-concurrent-write-and-ioctl-races.patch queue-3.18/x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.patch queue-3.18/usb-usbmon-remove-assignment-from-is_err-argument.patch queue-3.18/uas-fix-comparison-for-error-code.patch queue-3.18/netfilter-bridge-ebt_among-add-missing-match-size-checks.patch queue-3.18/staging-android-ashmem-fix-lockdep-issue-during-llseek.patch queue-3.18/netfilter-nat-cope-with-negative-port-range.patch queue-3.18/netfilter-x_tables-fix-missing-timer-initialization-in-xt_led.patch queue-3.18/tty-serial-atmel-add-new-version-check-for-usart.patch queue-3.18/input-matrix_keypad-fix-race-when-disabling-interrupts.patch

author maintainer Applied
#43 lore raw

Patch "fixup: sctp: verify size of a new chunk in _sctp_make_chunk()" has been added to the 4.4-stable tree

In reply to Greg Kroah-Hartman

This is a note to let you know that I've just added the patch titled

fixup: sctp: verify size of a new chunk in _sctp_make_chunk()

to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
fixup-sctp-verify-size-of-a-new-chunk-in-_sctp_make_chunk.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From [email protected] Fri Mar 16 14:27:34 2018

From: Greg Kroah-Hartman <[email protected]>
Date: Tue, 13 Mar 2018 10:56:00 +0100
Subject: fixup: sctp: verify size of a new chunk in _sctp_make_chunk()
To: Ben Hutchings <[email protected]>
Cc: [email protected], [email protected], Alexey Kodanev <[email protected]>, Marcelo Ricardo Leitner <[email protected]>, Neil Horman <[email protected]>, "David S. Miller" <[email protected]>
Message-ID: <[email protected]>
Content-Disposition: inline

From: Greg Kroah-Hartman <[email protected]>

Quoted 6 lines · Ben

Review

Quoted 3 lines
(quoted diff) +3 -0
+	int chunklen;
+
+	chunklen = sizeof(*chunk_hdr) + paylen;

I think this length still needs to be rounded up (with WORD_ROUND here, instead of SCTP_PAD4 upstream).

So here's a fix for this problem.

---
 net/sctp/sm_make_chunk.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/sctp/sm_make_chunk.c +1 -1
@@ -1369,7 +1369,7 @@ static struct sctp_chunk *_sctp_make_chu
 	struct sock *sk;
 	int chunklen;
 
-	chunklen = sizeof(*chunk_hdr) + paylen;
+	chunklen = WORD_ROUND(sizeof(*chunk_hdr) + paylen);
 	if (chunklen > SCTP_MAX_CHUNK_LEN)
 		goto nodata;
 

Patches currently in stable-queue which might be from [email protected] are

queue-4.4/tc358743-fix-register-i2c_rd-wr-function-fix.patch queue-4.4/netfilter-add-back-stackpointer-size-checks.patch queue-4.4/watchdog-hpwdt-fix-unused-variable-warning.patch queue-4.4/scsi-qla2xxx-fix-null-pointer-crash-due-to-active-timer-for-abts.patch queue-4.4/watchdog-hpwdt-smbios-check.patch queue-4.4/drm-amdgpu-notify-sbios-device-ready-before-send-request.patch queue-4.4/workqueue-allow-retrieval-of-current-task-s-work-struct.patch queue-4.4/loop-fix-lost-writes-caused-by-missing-flag.patch queue-4.4/rdma-ucma-limit-possible-option-size.patch queue-4.4/alsa-seq-don-t-allow-resizing-pool-in-use.patch queue-4.4/netfilter-x_tables-pack-percpu-counter-allocations.patch queue-4.4/serial-sh-sci-prevent-lockup-on-full-tty-buffers.patch queue-4.4/revert-arm-dts-logicpd-torpedo-fix-i2c1-pinmux.patch queue-4.4/serial-8250_pci-add-brainboxes-uc-260-4-port-serial-device.patch queue-4.4/arm-omap2-hide-omap3_save_secure_ram-on-non-omap3-builds.patch queue-4.4/usb-usbmon-read-text-within-supplied-buffer-size.patch queue-4.4/x86-mce-serialize-sysfs-changes.patch queue-4.4/alsa-hda-add-dock-and-led-support-for-hp-probook-640-g2.patch queue-4.4/netfilter-idletimer-be-syzkaller-friendly.patch queue-4.4/netfilter-use-skb_to_full_sk-in-ip_route_me_harder.patch queue-4.4/usb-gadget-f_fs-fix-use-after-free-in-ffs_fs_kill_sb.patch queue-4.4/usb-storage-add-jmicron-bridge-152d-2567-to-unusual_devs.h.patch queue-4.4/drm-radeon-fix-kv-harvesting.patch queue-4.4/usb-quirks-add-control-message-delay-for-1b1c-1b20.patch queue-4.4/x86-module-detect-and-skip-invalid-relocations.patch queue-4.4/ubi-fix-race-condition-between-ubi-volume-creation-and-udev.patch queue-4.4/drm-radeon-fix-deadlock-on-runtime-suspend.patch queue-4.4/scsi-qla2xxx-replace-fcport-alloc-with-qla2x00_alloc_fcport.patch queue-4.4/alsa-hda-add-dock-and-led-support-for-hp-elitebook-820-g3.patch queue-4.4/watchdog-hpwdt-check-source-of-nmi.patch queue-4.4/netfilter-ipv6-fix-use-after-free-write-in-nf_nat_ipv6_manip_pkt.patch queue-4.4/mips-bmips-do-not-mask-ipis-during-suspend.patch queue-4.4/netfilter-x_tables-pass-xt_counters-struct-instead-of-packet-counter.patch queue-4.4/staging-comedi-fix-comedi_nsamples_left.patch queue-4.4/rdma-ucma-check-that-user-doesn-t-overflow-qp-state.patch queue-4.4/fixup-sctp-verify-size-of-a-new-chunk-in-_sctp_make_chunk.patch queue-4.4/nospec-include-asm-barrier.h-dependency.patch queue-4.4/netfilter-ebtables-config_compat-don-t-trust-userland-offsets.patch queue-4.4/drm-amdgpu-fix-deadlock-on-runtime-suspend.patch queue-4.4/alsa-seq-more-protection-for-concurrent-write-and-ioctl-races.patch queue-4.4/nfs-fix-an-incorrect-type-in-struct-nfs_direct_req.patch queue-4.4/netfilter-nfnetlink_queue-fix-timestamp-attribute.patch queue-4.4/mips-ath25-check-for-kzalloc-allocation-failure.patch queue-4.4/x86-treat-r_x86_64_plt32-as-r_x86_64_pc32.patch queue-4.4/usb-usbmon-remove-assignment-from-is_err-argument.patch queue-4.4/bcache-don-t-attach-backing-with-duplicate-uuid.patch queue-4.4/kbuild-handle-builtin-dtb-file-names-containing-hyphens.patch queue-4.4/uas-fix-comparison-for-error-code.patch queue-4.4/drm-allow-determining-if-current-task-is-output-poll-worker.patch queue-4.4/netfilter-bridge-ebt_among-add-missing-match-size-checks.patch queue-4.4/staging-android-ashmem-fix-lockdep-issue-during-llseek.patch queue-4.4/netfilter-nat-cope-with-negative-port-range.patch queue-4.4/netfilter-x_tables-fix-missing-timer-initialization-in-xt_led.patch queue-4.4/ext4-inplace-xattr-block-update-fails-to-deduplicate-blocks.patch queue-4.4/input-tca8418_keypad-remove-double-read-of-key-event-register.patch queue-4.4/alsa-hda-realtek-fix-dock-line-out-volume-on-dell-precision-7520.patch queue-4.4/drm-amdgpu-fix-kv-harvesting.patch queue-4.4/drm-nouveau-fix-deadlock-on-runtime-suspend.patch queue-4.4/tty-serial-atmel-add-new-version-check-for-usart.patch queue-4.4/input-matrix_keypad-fix-race-when-disabling-interrupts.patch queue-4.4/mips-octeon-irq-check-for-null-return-on-kzalloc-allocation.patch queue-4.4/netfilter-x_tables-pass-xt_counters-struct-to-counter-allocator.patch queue-4.4/rdma-mlx5-fix-integer-overflow-while-resizing-cq.patch

author maintainer
#44 lore raw

PATCH 32/36 net: mpls: Pull common label check into helper

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: David Ahern <[email protected]>

commit b7b386f42f079b25b942c756820e36c6bd09b2ca upstream.

mpls_route_add and mpls_route_del have the same checks on the label. Move to a helper. Avoid duplicate extack messages in the next patch.

---
 net/mpls/af_mpls.c |   32 +++++++++++++++++---------------
 1 file changed, 17 insertions(+), 15 deletions(-)
net/mpls/af_mpls.c +17 -15
@@ -714,6 +714,19 @@ errout:
 	return err;
 }
 
+static bool mpls_label_ok(struct net *net, unsigned int index)
+{
+	/* Reserved labels may not be set */
+	if (index < MPLS_LABEL_FIRST_UNRESERVED)
+		return false;
+
+	/* The full 20 bit range may not be supported. */
+	if (index >= net->mpls.platform_labels)
+		return false;
+
+	return true;
+}
+
 static int mpls_route_add(struct mpls_route_config *cfg)
 {
 	struct mpls_route __rcu **platform_label;
@@ -732,12 +745,7 @@ static int mpls_route_add(struct mpls_ro
 		index = find_free_label(net);
 	}
 
-	/* Reserved labels may not be set */
-	if (index < MPLS_LABEL_FIRST_UNRESERVED)
-		goto errout;
-
-	/* The full 20 bit range may not be supported. */
-	if (index >= net->mpls.platform_labels)
+	if (!mpls_label_ok(net, index))
 		goto errout;
 
 	/* Append makes no sense with mpls */
@@ -798,12 +806,7 @@ static int mpls_route_del(struct mpls_ro
 
 	index = cfg->rc_label;
 
-	/* Reserved labels may not be removed */
-	if (index < MPLS_LABEL_FIRST_UNRESERVED)
-		goto errout;
-
-	/* The full 20 bit range may not be supported */
-	if (index >= net->mpls.platform_labels)
+	if (!mpls_label_ok(net, index))
 		goto errout;
 
 	mpls_route_update(net, index, NULL, &cfg->rc_nlinfo);
@@ -1162,10 +1165,9 @@ static int rtm_to_route_config(struct sk
 					   &cfg->rc_label))
 				goto errout;
 
-			/* Reserved labels may not be set */
-			if (cfg->rc_label < MPLS_LABEL_FIRST_UNRESERVED)
+			if (!mpls_label_ok(cfg->rc_nlinfo.nl_net,
+					   cfg->rc_label))
 				goto errout;
-
 			break;
 		}
 		case RTA_VIA:
author maintainer
#45 lore raw

PATCH 33/36 mpls, nospec: Sanitize array index in mpls_label_ok()

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Dan Williams <[email protected]>

commit 3968523f855050b8195134da951b87c20bd66130 upstream.

mpls_label_ok() validates that the 'platform_label' array index from a userspace netlink message payload is valid. Under speculation the mpls_label_ok() result may not resolve in the CPU pipeline until after the index is used to access an array element. Sanitize the index to zero to prevent userspace-controlled arbitrary out-of-bounds speculation, a precursor for a speculative execution side channel vulnerability.

Cc "David S. Miller" <[email protected]>
Cc Eric W. Biederman <[email protected]>

[bwh: Backported to 4.4:
- mpls_label_ok() doesn't take an extack parameter
- Drop change in mpls_getroute()]

---
 net/mpls/af_mpls.c |   22 +++++++++++++---------
 1 file changed, 13 insertions(+), 9 deletions(-)
net/mpls/af_mpls.c +13 -9
@@ -7,6 +7,7 @@
 #include <linux/if_arp.h>
 #include <linux/ipv6.h>
 #include <linux/mpls.h>
+#include <linux/nospec.h>
 #include <linux/vmalloc.h>
 #include <net/ip.h>
 #include <net/dst.h>
@@ -714,17 +715,20 @@ errout:
 	return err;
 }
 
-static bool mpls_label_ok(struct net *net, unsigned int index)
+static bool mpls_label_ok(struct net *net, unsigned int *index)
 {
+	bool is_ok = true;
+
 	/* Reserved labels may not be set */
-	if (index < MPLS_LABEL_FIRST_UNRESERVED)
-		return false;
+	if (*index < MPLS_LABEL_FIRST_UNRESERVED)
+		is_ok = false;
 
 	/* The full 20 bit range may not be supported. */
-	if (index >= net->mpls.platform_labels)
-		return false;
+	if (is_ok && *index >= net->mpls.platform_labels)
+		is_ok = false;
 
-	return true;
+	*index = array_index_nospec(*index, net->mpls.platform_labels);
+	return is_ok;
 }
 
 static int mpls_route_add(struct mpls_route_config *cfg)
@@ -745,7 +749,7 @@ static int mpls_route_add(struct mpls_ro
 		index = find_free_label(net);
 	}
 
-	if (!mpls_label_ok(net, index))
+	if (!mpls_label_ok(net, &index))
 		goto errout;
 
 	/* Append makes no sense with mpls */
@@ -806,7 +810,7 @@ static int mpls_route_del(struct mpls_ro
 
 	index = cfg->rc_label;
 
-	if (!mpls_label_ok(net, index))
+	if (!mpls_label_ok(net, &index))
 		goto errout;
 
 	mpls_route_update(net, index, NULL, &cfg->rc_nlinfo);
@@ -1166,7 +1170,7 @@ static int rtm_to_route_config(struct sk
 				goto errout;
 
 			if (!mpls_label_ok(cfg->rc_nlinfo.nl_net,
-					   cfg->rc_label))
+					   &cfg->rc_label))
 				goto errout;
 			break;
 		}
author maintainer
#46 lore raw

PATCH 34/36 dm io: fix duplicate bio completion due to missing ref count

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Mike Snitzer <[email protected]>

commit feb7695fe9fb83084aa29de0094774f4c9d4c9fc upstream.

If only a subset of the devices associated with multiple regions support a given special operation (eg. DISCARD) then the dec_count() that is used to set error for the region must increment the io->count.

Otherwise, when the dec_count() is called it can cause the dm-io caller's bio to be completed multiple times. As was reported against the dm-mirror target that had mirror legs with a mix of discard capabilities.

---
 drivers/md/dm-io.c |    1 +
 1 file changed, 1 insertion(+)
drivers/md/dm-io.c +1 -0
@@ -300,6 +300,7 @@ static void do_region(int rw, unsigned r
 	else if (rw & REQ_WRITE_SAME)
 		special_cmd_max_sectors = q->limits.max_write_same_sectors;
 	if ((rw & (REQ_DISCARD | REQ_WRITE_SAME)) && special_cmd_max_sectors == 0) {
+		atomic_inc(&io->count);
 		dec_count(io, region, -EOPNOTSUPP);
 		return;
 	}
author maintainer
#47 lore raw

PATCH 35/36 bpf, x64: implement retpoline for tail call

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Daniel Borkmann <[email protected]>

[ upstream commit a493a87f38cfa48caaa95c9347be2d914c6fdf29 ]

Implement a retpoline [0] for the BPF tail call JIT'ing that converts the indirect jump via jmp %rax that is used to make the long jump into another JITed BPF image. Since this is subject to speculative execution, we need to control the transient instruction sequence here as well when CONFIG_RETPOLINE is set, and direct it into a pause + lfence loop. The latter aligns also with what gcc / clang emits (e.g. [1]).

JIT dump after patch:

  # bpftool p d x i 1
   0: (18) r2 = map[id:1]
   2: (b7) r3 = 0
   3: (85) call bpf_tail_call#12
   4: (b7) r0 = 2
   5: (95) exit

With CONFIG_RETPOLINE:

  # bpftool p d j i 1
  [...]
  33:	cmp    %edx,0x24(%rsi)
  36:	jbe    0x0000000000000072  |*
  38:	mov    0x24(%rbp),%eax
  3e:	cmp    $0x20,%eax
  41:	ja     0x0000000000000072  |
  43:	add    $0x1,%eax
  46:	mov    %eax,0x24(%rbp)
  4c:	mov    0x90(%rsi,%rdx,8),%rax
  54:	test   %rax,%rax
  57:	je     0x0000000000000072  |
  59:	mov    0x28(%rax),%rax
  5d:	add    $0x25,%rax
  61:	callq  0x000000000000006d  |+
  66:	pause                      |
  68:	lfence                     |
  6b:	jmp    0x0000000000000066  |
  6d:	mov    %rax,(%rsp)         |
  71:	retq                       |
  72:	mov    $0x2,%eax
  [...]

* relative fall-through jumps in error case
+ retpoline for indirect jump

Without CONFIG_RETPOLINE:

  # bpftool p d j i 1
  [...]
  33:	cmp    %edx,0x24(%rsi)
  36:	jbe    0x0000000000000063  |*
  38:	mov    0x24(%rbp),%eax
  3e:	cmp    $0x20,%eax
  41:	ja     0x0000000000000063  |
  43:	add    $0x1,%eax
  46:	mov    %eax,0x24(%rbp)
  4c:	mov    0x90(%rsi,%rdx,8),%rax
  54:	test   %rax,%rax
  57:	je     0x0000000000000063  |
  59:	mov    0x28(%rax),%rax
  5d:	add    $0x25,%rax
  61:	jmpq   *%rax               |-
  63:	mov    $0x2,%eax
  [...]

* relative fall-through jumps in error case
- plain indirect jump as before

[0] https://support.google.com/faqs/answer/7625886
[1] https://github.com/gcc-mirror/gcc/commit/a31e654fa107be968b802786d747e962c2fcdb2b

---
 arch/x86/include/asm/nospec-branch.h |   37 +++++++++++++++++++++++++++++++++++
 arch/x86/net/bpf_jit_comp.c          |    9 ++++----
 2 files changed, 42 insertions(+), 4 deletions(-)
arch/x86/include/asm/nospec-branch.h +37 -0
@@ -195,4 +195,41 @@ static inline void vmexit_fill_RSB(void)
 }
 
 #endif /* __ASSEMBLY__ */
+
+/*
+ * Below is used in the eBPF JIT compiler and emits the byte sequence
+ * for the following assembly:
+ *
+ * With retpolines configured:
+ *
+ *    callq do_rop
+ *  spec_trap:
+ *    pause
+ *    lfence
+ *    jmp spec_trap
+ *  do_rop:
+ *    mov %rax,(%rsp)
+ *    retq
+ *
+ * Without retpolines configured:
+ *
+ *    jmp *%rax
+ */
+#ifdef CONFIG_RETPOLINE
+# define RETPOLINE_RAX_BPF_JIT_SIZE	17
+# define RETPOLINE_RAX_BPF_JIT()				\
+	EMIT1_off32(0xE8, 7);	 /* callq do_rop */		\
+	/* spec_trap: */					\
+	EMIT2(0xF3, 0x90);       /* pause */			\
+	EMIT3(0x0F, 0xAE, 0xE8); /* lfence */			\
+	EMIT2(0xEB, 0xF9);       /* jmp spec_trap */		\
+	/* do_rop: */						\
+	EMIT4(0x48, 0x89, 0x04, 0x24); /* mov %rax,(%rsp) */	\
+	EMIT1(0xC3);             /* retq */
+#else
+# define RETPOLINE_RAX_BPF_JIT_SIZE	2
+# define RETPOLINE_RAX_BPF_JIT()				\
+	EMIT2(0xFF, 0xE0);	 /* jmp *%rax */
+#endif
+
 #endif /* _ASM_X86_NOSPEC_BRANCH_H_ */
arch/x86/net/bpf_jit_comp.c +5 -4
@@ -12,6 +12,7 @@
 #include <linux/filter.h>
 #include <linux/if_vlan.h>
 #include <asm/cacheflush.h>
+#include <asm/nospec-branch.h>
 #include <linux/bpf.h>
 
 int bpf_jit_enable __read_mostly;
@@ -269,7 +270,7 @@ static void emit_bpf_tail_call(u8 **ppro
 	EMIT2(0x89, 0xD2);                        /* mov edx, edx */
 	EMIT3(0x39, 0x56,                         /* cmp dword ptr [rsi + 16], edx */
 	      offsetof(struct bpf_array, map.max_entries));
-#define OFFSET1 43 /* number of bytes to jump */
+#define OFFSET1 (41 + RETPOLINE_RAX_BPF_JIT_SIZE) /* number of bytes to jump */
 	EMIT2(X86_JBE, OFFSET1);                  /* jbe out */
 	label1 = cnt;
 
@@ -278,7 +279,7 @@ static void emit_bpf_tail_call(u8 **ppro
 	 */
 	EMIT2_off32(0x8B, 0x85, -STACKSIZE + 36); /* mov eax, dword ptr [rbp - 516] */
 	EMIT3(0x83, 0xF8, MAX_TAIL_CALL_CNT);     /* cmp eax, MAX_TAIL_CALL_CNT */
-#define OFFSET2 32
+#define OFFSET2 (30 + RETPOLINE_RAX_BPF_JIT_SIZE)
 	EMIT2(X86_JA, OFFSET2);                   /* ja out */
 	label2 = cnt;
 	EMIT3(0x83, 0xC0, 0x01);                  /* add eax, 1 */
@@ -292,7 +293,7 @@ static void emit_bpf_tail_call(u8 **ppro
 	 *   goto out;
 	 */
 	EMIT3(0x48, 0x85, 0xC0);		  /* test rax,rax */
-#define OFFSET3 10
+#define OFFSET3 (8 + RETPOLINE_RAX_BPF_JIT_SIZE)
 	EMIT2(X86_JE, OFFSET3);                   /* je out */
 	label3 = cnt;
 
@@ -305,7 +306,7 @@ static void emit_bpf_tail_call(u8 **ppro
 	 * rdi == ctx (1st arg)
 	 * rax == prog->bpf_func + prologue_size
 	 */
-	EMIT2(0xFF, 0xE0);                        /* jmp rax */
+	RETPOLINE_RAX_BPF_JIT();
 
 	/* out: */
 	BUILD_BUG_ON(cnt - label1 != OFFSET1);
author maintainer
#48 lore raw

PATCH 36/36 btrfs: preserve i_mode if __btrfs_set_acl() fails

In reply to Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.

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

From: Ernesto A. Fernández <[email protected]>

commit d7d824966530acfe32b94d1ed672e6fe1638cd68 upstream.

When changing a file's acl mask, btrfs_set_acl() will first set the group bits of i_mode to the value of the mask, and only then set the actual extended attribute representing the new acl.

If the second part fails (due to lack of space, for example) and the file had no acl attribute to begin with, the system will from now on assume that the mask permission bits are actual group permission bits, potentially granting access to the wrong users.

Prevent this by restoring the original mode bits if __btrfs_set_acl fails.

---
 fs/btrfs/acl.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
fs/btrfs/acl.c +5 -1
@@ -118,13 +118,17 @@ out:
 int btrfs_set_acl(struct inode *inode, struct posix_acl *acl, int type)
 {
 	int ret;
+	umode_t old_mode = inode->i_mode;
 
 	if (type == ACL_TYPE_ACCESS && acl) {
 		ret = posix_acl_update_mode(inode, &inode->i_mode, &acl);
 		if (ret)
 			return ret;
 	}
-	return __btrfs_set_acl(NULL, inode, acl, type);
+	ret = __btrfs_set_acl(NULL, inode, acl, type);
+	if (ret)
+		inode->i_mode = old_mode;
+	return ret;
 }
 
 /*
#49 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.121 release. There are 36 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 Mon Mar 12 00:17:54 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 9 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.121-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

Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5.

No merge conflicts and no visible issues in dmesg or general usage.

Thanks!
Nathan

author maintainer
#50 lore raw
Quoted 15 lines · Nathan Chancellor
Quoted 14 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.121 release. There are 36 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 Mon Mar 12 00:17:54 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.121-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.

Quoted 8 lines
Quoted 4 lines

thanks,

greg k-h

Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5.

No merge conflicts and no visible issues in dmesg or general usage.

That was fast, thanks!

greg k-h

#51 lore raw
Quoted 21 lines · Greg Kroah-Hartman
Quoted 20 lines · Nathan Chancellor
Quoted 18 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.121 release. There are 36 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 Mon Mar 12 00:17:54 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.121-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

Quoted 7 lines
Quoted 3 lines

Merged, compiled, and flashed onto my Pixel 2 XL and OnePlus 5.

No merge conflicts and no visible issues in dmesg or general usage.

That was fast, thanks!

greg k-h

I happened to run the stable queue since there was no RC when I decided to build so the timing worked out!

Nathan

#52 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.121 release. There are 36 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 Mon Mar 12 00:17:54 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 9 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.121-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

#53 lore raw
In reply to Greg Kroah-Hartman
stable-rc/linux-4.4.y boot: 116 boots: 1 failed, 108 passed with 5 offline, 2 untried/unknown (v4.4.120-37-gce7ba34ae77c)

stable-rc/linux-4.4.y boot: 116 boots: 1 failed, 108 passed with 5 offline, 2 untried/unknown (v4.4.120-37-gce7ba34ae77c)

Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.120-37-gce7ba34ae77c/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.120-37-gce7ba34ae77c/

Tree: stable-rc
Branch: linux-4.4.y
Git Describe: v4.4.120-37-gce7ba34ae77c
Git Commit: ce7ba34ae77cd9c453322684a048f2ea9fef4cb5
Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 59 unique boards, 20 SoC families, 16 builds out of 178

Boot Regressions Detected:

arm:

mvebu_v7_defconfig:
armada-375-db:
lab-free-electrons: new failure (last pass: v4.4.120)

Boot Failure Detected:

arm:

    mvebu_v7_defconfig
        armada-375-db: 1 failed lab

Offline Platforms:

arm:

multi_v7_defconfig:
exynos5410-odroidxu: 1 offline lab
meson8b-odroidc1: 1 offline lab
vf610-colibri-eval-v3: 1 offline lab

exynos_defconfig:
exynos5410-odroidxu: 1 offline lab

imx_v6_v7_defconfig:
vf610-colibri-eval-v3: 1 offline lab

---
For more info write to <[email protected]>

#54 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.121 release. There are 36 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 Mon Mar 12 00:17:54 UTC 2018. Anything received after that time might be too late.

Build results:

	total: 145 pass: 145 fail: 0
Qemu test results:
	total: 127 pass: 127 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

#55 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.121 release. There are 36 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 Mon Mar 12 00:17:54 UTC 2018. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
        https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.121-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

Results from Linaro’s test farm.
No regressions on arm64 and arm.

NOTE:
x86_64 results not available due to infrastructure issue.

Summary
------------------------------------------------------------------------

kernel: 4.4.121
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 8b5ab55d254f36e89b1b53aeac7223d2d102483e
git describe: v4.4.121
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.121

No regressions (compared to build v4.4.120-37-gce7ba34ae77c)

Boards, architectures and test suites:
-------------------------------------

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 34, skip: 29,
* libhugetlbfs - pass: 90, skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 53,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 998, skip: 152,
* ltp-timers-tests - pass: 12, skip: 1,

x15 - arm
* boot - pass: 20,
* kselftest - pass: 33, skip: 29,
* libhugetlbfs - pass: 87, skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1052, skip: 98,
* ltp-timers-tests - pass: 12, skip: 1,

Hikey test results,

Summary
------------------------------------------------------------------------

kernel: 4.4.121-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git tag: 4.4.121-rc1-hikey-20180310-148
git commit: dcb0bc445118b65d2b424ce081255289c3f33ce7
git describe: 4.4.121-rc1-hikey-20180310-148
Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.121-rc1-hikey-20180310-148

No regressions (compared to build 4.4.120-rc1-hikey-20180302-146)

Boards, architectures and test suites:
-------------------------------------

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 31, skip: 32,
* libhugetlbfs - pass: 90, skip: 1,
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 28, skip: 53,
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2,
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4,
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 996, skip: 154,
* ltp-timers-tests - pass: 12, skip: 1,

--
Linaro QA (beta)
https://qa-reports.linaro.org