linux-stable.git/drivers, branch v5.0.2

ath9k: Avoid OF no-EEPROM quirks without qca,no-eeprom

2019-03-13T21:01:31+00:00

commit ce938231bd3b1d7af3cbd8836f084801090470e1 upstream.

ath9k_of_init() function[0] was initially written on the assumption that
if someone had an explicit ath9k OF node that "there must be something
wrong, why would someone add an OF node if everything is fine"[1]
(Quoting Martin Blumenstingl )

"it turns out it's not that simple. with your requirements I'm now aware
of two use-cases where the current code in ath9k_of_init() doesn't work
without modifications"[1]

The "your requirements" Martin speaks of is the result of the fact that I
have a device (PowerCloud Systems CR5000) has some kind of default - not
unique mac address - set and requires to set the correct MAC address via
mac-address devicetree property, however:

"some cards come with a physical EEPROM chip [or OTP] so "qca,no-eeprom"
should not be set (your use-case). in this case AH_USE_EEPROM should be
set (which is the default when there is no OF node)"[1]

The other use case is:

the firmware on some PowerMac G5 seems to add a OF node for the ath9k
card automatically. depending on the EEPROM on the card AH_NO_EEP_SWAP
should be unset (which is the default when there is no OF node). see [3]

After this patch to ath9k_of_init() the new behavior will be:

    if there's no OF node then everything is the same as before
    if there's an empty OF node then ath9k will use the hardware EEPROM
      (before ath9k would fail to initialize because no EEPROM data was
      provided by userspace)
    if there's an OF node with only a MAC address then ath9k will use
      the MAC address and the hardware EEPROM (see the case above)
    with "qca,no-eeprom" EEPROM data from userspace will be requested.
      the behavior here will not change
[1]

Martin provides additional background on EEPROM swapping[1].

Thanks to Christian Lamparter  for all his help on
troubleshooting this issue and the basis for this patch.

[0]https://elixir.bootlin.com/linux/v4.20-rc7/source/drivers/net/wireless/ath/ath9k/init.c#L615
[1]https://github.com/openwrt/openwrt/pull/1645#issuecomment-448027058
[2]https://github.com/openwrt/openwrt/pull/1613
[3]https://patchwork.kernel.org/patch/10241731/

Fixes: 138b41253d9c ("ath9k: parse the device configuration from an OF node")
Reviewed-by: Martin Blumenstingl 
Tested-by: Martin Blumenstingl 
Signed-off-by: Daniel F. Dickinson 
Signed-off-by: Kalle Valo 
Cc: Christian Lamparter 
Signed-off-by: Greg Kroah-Hartman

staging: erofs: compressed_pages should not be accessed again after freed

2019-03-13T21:01:31+00:00

commit af692e117cb8cd9d3d844d413095775abc1217f9 upstream.

This patch resolves the following page use-after-free issue,
z_erofs_vle_unzip:
    ...
    for (i = 0; i < nr_pages; ++i) {
        ...
        z_erofs_onlinepage_endio(page);  (1)
    }

    for (i = 0; i < clusterpages; ++i) {
        page = compressed_pages[i];

        if (page->mapping == mngda)      (2)
            continue;
        /* recycle all individual staging pages */
        (void)z_erofs_gather_if_stagingpage(page_pool, page); (3)
        WRITE_ONCE(compressed_pages[i], NULL);
    }
    ...

After (1) is executed, page is freed and could be then reused, if
compressed_pages is scanned after that, it could fall info (2) or
(3) by mistake and that could finally be in a mess.

This patch aims to solve the above issue only with little changes
as much as possible in order to make the fix backport easier.

Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc:  # 4.19+
Signed-off-by: Gao Xiang 
Reviewed-by: Chao Yu 
Signed-off-by: Greg Kroah-Hartman

staging: erofs: keep corrupted fs from crashing kernel in erofs_namei()

2019-03-13T21:01:31+00:00

commit 419d6efc50e94bcf5d6b35cd8c71f79edadec564 upstream.

As Al pointed out, "
... and while we are at it, what happens to
	unsigned int nameoff = le16_to_cpu(de[mid].nameoff);
	unsigned int matched = min(startprfx, endprfx);

	struct qstr dname = QSTR_INIT(data + nameoff,
		unlikely(mid >= ndirents - 1) ?
			maxsize - nameoff :
			le16_to_cpu(de[mid + 1].nameoff) - nameoff);

	/* string comparison without already matched prefix */
	int ret = dirnamecmp(name, &dname, &matched);
if le16_to_cpu(de[...].nameoff) is not monotonically increasing?  I.e.
what's to prevent e.g. (unsigned)-1 ending up in dname.len?

Corrupted fs image shouldn't oops the kernel.. "

Revisit the related lookup flow to address the issue.

Fixes: d72d1ce60174 ("staging: erofs: add namei functions")
Cc:  # 4.19+
Suggested-by: Al Viro 
Signed-off-by: Gao Xiang 
Signed-off-by: Greg Kroah-Hartman

Revert "PCI/PME: Implement runtime PM callbacks"

2019-03-13T21:01:31+00:00

commit c528f7bd362b097eeeafa6fbbeccd9750b79c7ba upstream.

This reverts commit 0e157e52860441cb26051f131dd0b5ae3187a07b.

Heiner reported that the commit in question prevents his network adapter
from triggering PME and waking up when network cable is plugged.

The commit tried to prevent root port waking up from D3cold immediately but
looks like disabing root port PME interrupt is not the right way to fix
that issue so revert it now.  The patch following proposes an alternative
solution to that issue.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=202103
Fixes: 0e157e528604 ("PCI/PME: Implement runtime PM callbacks")
Reported-by: Heiner Kallweit 
Tested-by: Heiner Kallweit 
Signed-off-by: Mika Westerberg 
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
CC: stable@vger.kernel.org	# v4.20+
Signed-off-by: Greg Kroah-Hartman

media: Revert "media: rc: some events are dropped by userspace"

2019-03-13T21:01:31+00:00

commit 05f0edadcc5fccdfc0676825b3e70e75dc0a8a84 upstream.

When an rc device is created, we do not know what key codes it will
support, since a new keymap might be loaded at some later point. So,
we set all keybit in the input device.

The uevent for the input device includes all the key codes, of which
there are now 768. This overflows the size of the uevent
(UEVENT_BUFFER_SIZE) and no event is generated.

Revert for now until we figure out a different solution.

This reverts commit fec225a04330d0f222d24feb5bea045526031675.

Cc:  # 4.20+
Reported-by: Christian Holpert 
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

scsi: aacraid: Fix missing break in switch statement

2019-03-13T21:01:30+00:00

commit 5e420fe635813e5746b296cfc8fff4853ae205a2 upstream.

Add missing break statement and fix identation issue.

This bug was found thanks to the ongoing efforts to enable
-Wimplicit-fallthrough.

Fixes: 9cb62fa24e0d ("aacraid: Log firmware AIF messages")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

iscsi_ibft: Fix missing break in switch statement

2019-03-13T21:01:30+00:00

commit df997abeebadaa4824271009e2d2b526a70a11cb upstream.

Add missing break statement in order to prevent the code from falling
through to case ISCSI_BOOT_TGT_NAME, which is unnecessary.

This bug was found thanks to the ongoing efforts to enable
-Wimplicit-fallthrough.

Fixes: b33a84a38477 ("ibft: convert iscsi_ibft module to iscsi boot lib")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Greg Kroah-Hartman

Input: elan_i2c - add id for touchpad found in Lenovo s21e-20

2019-03-13T21:01:29+00:00

commit e154ab69321ce2c54f19863d75c77b4e2dc9d365 upstream.

Lenovo s21e-20 uses ELAN0601 in its ACPI tables for the Elan touchpad.

Signed-off-by: Vincent Batts 
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: wacom_serial4 - add support for Wacom ArtPad II tablet

2019-03-13T21:01:29+00:00

commit 44fc95e218a09d7966a9d448941fdb003f6bb69f upstream.

Tablet initially begins communicating at 9600 baud, so this command
should be used to connect to the device:

    $ inputattach --daemon --baud 9600 --wacom_iv /dev/ttyS0

https://github.com/linuxwacom/xf86-input-wacom/issues/40

Signed-off-by: Jason Gerecke 
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

media: uvcvideo: Fix 'type' check leading to overflow

2019-03-13T21:01:29+00:00

commit 47bb117911b051bbc90764a8bff96543cbd2005f upstream.

When initially testing the Camera Terminal Descriptor wTerminalType
field (buffer[4]), no mask is used. Later in the function, the MSB is
overloaded to store the descriptor subtype, and so a mask of 0x7fff
is used to check the type.

If a descriptor is specially crafted to set this overloaded bit in the
original wTerminalType field, the initial type check will fail (falling
through, without adjusting the buffer size), but the later type checks
will pass, assuming the buffer has been made suitably large, causing an
overflow.

Avoid this problem by checking for the MSB in the wTerminalType field.
If the bit is set, assume the descriptor is bad, and abort parsing it.

Originally reported here:
https://groups.google.com/forum/#!topic/syzkaller/Ot1fOE6v1d8
A similar (non-compiling) patch was provided at that time.

Reported-by: syzbot 
Signed-off-by: Alistair Strachan 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman