Skip to contentSkip to conversation

selftests/efivarfs: add required kernel configs

PATCH In review Sasha Levin 2 participants 8 messages Oct 5, 2018 – Oct 10, 2018 Stable branch

lore
Share & tools
lore

Sasha Levin

author maintainer
#0 lore raw

PATCH 1/6 selftests/efivarfs: add required kernel configs

From: Lei Yang <[email protected]>

[ Upstream commit 53cf59d6c0ad3edc4f4449098706a8f8986258b6 ]

add config file

---
 tools/testing/selftests/efivarfs/config | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 tools/testing/selftests/efivarfs/config
tools/testing/selftests/efivarfs/config new file +1 -0
new file mode 100644
index 000000000000..4e151f1005b2
@@ -0,0 +1 @@
+CONFIG_EFIVAR_FS=y
Signature · 1 line
2.17.1
author maintainer
#1 lore raw

PATCH 2/6 mfd: omap-usb-host: Fix dts probe of children

From: Tony Lindgren <[email protected]>

[ Upstream commit 10492ee8ed9188d6d420e1f79b2b9bdbc0624e65 ]

It currently only works if the parent bus uses "simple-bus". We currently try to probe children with non-existing compatible values. And we're missing .probe.

I noticed this while testing devices configured to probe using ti-sysc interconnect target module driver. For that we also may want to rebind the driver, so let's remove __init and __exit.

---
 drivers/mfd/omap-usb-host.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/mfd/omap-usb-host.c +6 -5
index 83dab2f0a50e..c59dc55de803 100644
@@ -558,8 +558,8 @@ static int usbhs_omap_get_dt_pdata(struct device *dev,
 }
 
 static const struct of_device_id usbhs_child_match_table[] = {
-	{ .compatible = "ti,omap-ehci", },
-	{ .compatible = "ti,omap-ohci", },
+	{ .compatible = "ti,ehci-omap", },
+	{ .compatible = "ti,ohci-omap3", },
 	{ }
 };
 
@@ -886,6 +886,7 @@ static struct platform_driver usbhs_omap_driver = {
 		.pm		= &usbhsomap_dev_pm_ops,
 		.of_match_table = usbhs_omap_dt_ids,
 	},
+	.probe		= usbhs_omap_probe,
 	.remove		= usbhs_omap_remove,
 };
 
@@ -895,9 +896,9 @@ MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
 MODULE_LICENSE("GPL v2");
 MODULE_DESCRIPTION("usb host common core driver for omap EHCI and OHCI");
 
-static int __init omap_usbhs_drvinit(void)
+static int omap_usbhs_drvinit(void)
 {
-	return platform_driver_probe(&usbhs_omap_driver, usbhs_omap_probe);
+	return platform_driver_register(&usbhs_omap_driver);
 }
 
 /*
@@ -909,7 +910,7 @@ static int __init omap_usbhs_drvinit(void)
  */
 fs_initcall_sync(omap_usbhs_drvinit);
 
-static void __exit omap_usbhs_drvexit(void)
+static void omap_usbhs_drvexit(void)
 {
 	platform_driver_unregister(&usbhs_omap_driver);
 }
Signature · 1 line
2.17.1
author maintainer
#2 lore raw

PATCH 3/6 stmmac: fix valid numbers of unicast filter entries

In reply to Sasha Levin

From: Jongsung Kim <[email protected]>

[ Upstream commit edf2ef7242805e53ec2e0841db26e06d8bc7da70 ]

Synopsys DWC Ethernet MAC can be configured to have 1..32, 64, or 128 unicast filter entries. (Table 7-8 MAC Address Registers from databook) Fix dwmac1000_validate_ucast_entries() to accept values between 1 and 32 in addition.

---
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c +2 -3
index 58a1a0a423d4..4d718e738522 100644
@@ -85,7 +85,7 @@ static int dwmac1000_validate_mcast_bins(int mcast_bins)
 
 /* This function validates the number of Unicast address entries supported
  * by a particular Synopsys 10/100/1000 controller. The Synopsys controller
- * supports 1, 32, 64, or 128 Unicast filter entries for it's Unicast filter
+ * supports 1..32, 64, or 128 Unicast filter entries for it's Unicast filter
  * logic. This function validates a valid, supported configuration is
  * selected, and defaults to 1 Unicast address if an unsupported
  * configuration is selected.
@@ -95,8 +95,7 @@ static int dwmac1000_validate_ucast_entries(int ucast_entries)
 	int x = ucast_entries;
 
 	switch (x) {
-	case 1:
-	case 32:
+	case 1 ... 32:
 	case 64:
 	case 128:
 		break;
Signature · 1 line
2.17.1
author maintainer
#3 lore raw

PATCH 4/6 net: hp100: fix always-true check for link up state

In reply to Sasha Levin

From: Colin Ian King <[email protected]>

[ Upstream commit a7f38002fb69b44f8fc622ecb838665d0b8666af ]

The operation ~(p100_inb(VG_LAN_CFG_1) & HP100_LINK_UP) returns a value that is always non-zero and hence the wait for the link to drop always terminates prematurely. Fix this by using a logical not operator instead of a bitwise complement. This issue has been in the driver since pre-2.6.12-rc2.

Detected by CoverityScan, CID#114157 ("Logical vs. bitwise operator")

---
 drivers/net/ethernet/hp/hp100.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/hp/hp100.c +1 -1
index 76a6e0c77d69..034471003249 100644
@@ -2637,7 +2637,7 @@ static int hp100_login_to_vg_hub(struct net_device *dev, u_short force_relogin)
 		/* Wait for link to drop */
 		time = jiffies + (HZ / 10);
 		do {
-			if (~(hp100_inb(VG_LAN_CFG_1) & HP100_LINK_UP_ST))
+			if (!(hp100_inb(VG_LAN_CFG_1) & HP100_LINK_UP_ST))
 				break;
 			if (!in_interrupt())
 				schedule_timeout_interruptible(1);
Signature · 1 line
2.17.1
author maintainer
#4 lore raw

PATCH 5/6 floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl

In reply to Sasha Levin

From: Andy Whitcroft <[email protected]>

[ Upstream commit 65eea8edc315589d6c993cf12dbb5d0e9ef1fe4e ]

The final field of a floppy_struct is the field "name", which is a pointer to a string in kernel memory. The kernel pointer should not be copied to user memory. The FDGETPRM ioctl copies a floppy_struct to user memory, including this "name" field. This pointer cannot be used by the user and it will leak a kernel address to user-space, which will reveal the location of kernel code and data and undermine KASLR protection.

Model this code after the compat ioctl which copies the returned data to a previously cleared temporary structure on the stack (excluding the name pointer) and copy out to userspace from there. As we already have an inparam union with an appropriate member and that memory is already cleared even for read only calls make use of that as a temporary store.

Based on an initial patch by Brian Belleville.

CVE-2018-7755

Broke up long line.

---
 drivers/block/floppy.c | 3 +++
 1 file changed, 3 insertions(+)
drivers/block/floppy.c +3 -0
index 56d46ffb08e1..f824836d2e7a 100644
@@ -3459,6 +3459,9 @@ static int fd_locked_ioctl(struct block_device *bdev, fmode_t mode, unsigned int
 					  (struct floppy_struct **)&outparam);
 		if (ret)
 			return ret;
+		memcpy(&inparam.g, outparam,
+				offsetof(struct floppy_struct, name));
+		outparam = &inparam.g;
 		break;
 	case FDMSGON:
 		UDP->flags |= FTD_MSG;
Signature · 1 line
2.17.1
author maintainer
#5 lore raw

PATCH 6/6 ubifs: Check for name being NULL while mounting

In reply to Sasha Levin

From: Richard Weinberger <[email protected]>

[ Upstream commit 37f31b6ca4311b94d985fb398a72e5399ad57925 ]

The requested device name can be NULL or an empty string. Check for that and refuse to continue. UBIFS has to do this manually since we cannot use mount_bdev(), which checks for this condition.

Fixes 1e51764a3c2ac ("UBIFS: add new flash file system")
Reported-by [email protected]
---
 fs/ubifs/super.c | 3 +++
 1 file changed, 3 insertions(+)
fs/ubifs/super.c +3 -0
index 2f7a74e73b7d..a6a2108bf620 100644
@@ -1917,6 +1917,9 @@ static struct ubi_volume_desc *open_ubi(const char *name, int mode)
 	int dev, vol;
 	char *endptr;
 
+	if (!name || !*name)
+		return ERR_PTR(-EINVAL);
+
 	/* First, try to open using the device node path method */
 	ubi = ubi_open_volume_path(name, mode);
 	if (!IS_ERR(ubi))
Signature · 1 line
2.17.1
#6 lore raw

Re: [PATCH AUTOSEL 3.18 6/6] ubifs: Check for name being NULL while mounting

Sasha,

Am Freitag, 5. Oktober 2018, 18:17:50 CEST schrieb Sasha Levin:

Quoted 4 lines

From: Richard Weinberger <[email protected]>

[ Upstream commit 37f31b6ca4311b94d985fb398a72e5399ad57925 ]

Quoted 8 lines

The requested device name can be NULL or an empty string. Check for that and refuse to continue. UBIFS has to do this manually since we cannot use mount_bdev(), which checks for this condition.

Fixes 1e51764a3c2ac ("UBIFS: add new flash file system")
Reported-by [email protected]

I'm not sure whether it makes sense to apply this patch to stable.
1. You need to be the real root to hit this code path.
2. Access is read-only, for an attacker it is useless.

If we look at the code:

        if (name[0] != 'u' || name[1] != 'b' || name[2] != 'i')
                return ERR_PTR(-EINVAL);

        /* ubi:NAME method */
        if ((name[3] == ':' || name[3] == '!') && name[4] != '\0')

name can be NULL, so we access just a few bytes.

Thanks,
//richard

author maintainer
#7 lore raw

Re: [PATCH AUTOSEL 3.18 6/6] ubifs: Check for name being NULL while mounting

Quoted 27 lines · Richard Weinberger

Sasha,

Am Freitag, 5. Oktober 2018, 18:17:50 CEST schrieb Sasha Levin:

Quoted 4 lines

From: Richard Weinberger <[email protected]>

[ Upstream commit 37f31b6ca4311b94d985fb398a72e5399ad57925 ]

Quoted 8 lines

The requested device name can be NULL or an empty string. Check for that and refuse to continue. UBIFS has to do this manually since we cannot use mount_bdev(), which checks for this condition.

Fixes 1e51764a3c2ac ("UBIFS: add new flash file system")
Reported-by [email protected]

I'm not sure whether it makes sense to apply this patch to stable.
1. You need to be the real root to hit this code path.
2. Access is read-only, for an attacker it is useless.

If we look at the code:

       if (name[0] != 'u' || name[1] != 'b' || name[2] != 'i')
               return ERR_PTR(-EINVAL);

       /* ubi:NAME method */
       if ((name[3] == ':' || name[3] == '!') && name[4] != '\0')
Quoted 4 lines

name can be NULL, so we access just a few bytes.

Thanks,
//richard

Hi Richard,

I wasn't really looking at it from a security perspective. My thought process was that if a user (root or not) is doing action A, expecting result B but instead unexpectedly sees result C then it's a bug worth fixing in stable.

If you think it's a risky change for stable I'd be happy to drop it.

--
Thanks,
Sasha