selftests/efivarfs: add required kernel configs
Sasha Levin
maintainerPATCH 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
@@ -0,0 +1 @@ +CONFIG_EFIVAR_FS=y
Signature · 1 line
2.17.1
Sasha Levin
maintainerPATCH 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
@@ -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
Sasha Levin
maintainerPATCH 3/6 stmmac: fix valid numbers of unicast filter entries
In reply to Sasha LevinFrom: 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
@@ -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
Sasha Levin
maintainerPATCH 4/6 net: hp100: fix always-true check for link up state
In reply to Sasha LevinFrom: 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
@@ -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
Sasha Levin
maintainerPATCH 5/6 floppy: Do not copy a kernel pointer to user memory in FDGETPRM ioctl
In reply to Sasha LevinFrom: 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
@@ -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
Sasha Levin
maintainerPATCH 6/6 ubifs: Check for name being NULL while mounting
In reply to Sasha LevinFrom: 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.
--- fs/ubifs/super.c | 3 +++ 1 file changed, 3 insertions(+)
fs/ubifs/super.c +3 -0
@@ -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
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]Signed-off-by Richard Weinberger <[email protected]>Signed-off-by Sasha Levin <[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
Sasha Levin
maintainerRe: [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]Signed-off-by Richard Weinberger <[email protected]>Signed-off-by Sasha Levin <[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