kernel/linux.git, branch v5.4.2

Linux 5.4.2

2019-12-04T21:31:09+00:00

platform/x86: hp-wmi: Fix ACPI errors caused by passing 0 as input size

2019-12-04T21:31:08+00:00

commit f3e4f3fc8ee9729c4b1b27a478c68b713df53c0c upstream. The AML code implementing the WMI methods creates a variable length field to hold the input data we pass like this: CreateDWordField (Arg1, 0x0C, DSZI) Local5 = DSZI /* \HWMC.DSZI */ CreateField (Arg1, 0x80, (Local5 * 0x08), DAIN) If we pass 0 as bios_args.datasize argument then (Local5 * 0x08) is 0 which results in these errors: [ 71.973305] ACPI BIOS Error (bug): Attempt to CreateField of length zero (20190816/dsopcode-133) [ 71.973332] ACPI Error: Aborting method \HWMC due to previous error (AE_AML_OPERAND_VALUE) (20190816/psparse-529) [ 71.973413] ACPI Error: Aborting method \_SB.WMID.WMAA due to previous error (AE_AML_OPERAND_VALUE) (20190816/psparse-529) And in our HPWMI_WIRELESS2_QUERY calls always failing. for read commands like HPWMI_WIRELESS2_QUERY the DSZI value is not used / checked, except for read commands where extra input is needed to specify exactly what to read. So for HPWMI_WIRELESS2_QUERY we can safely pass the size of the expected output as insize to hp_wmi_perform_query(), as we are already doing for all other HPWMI_READ commands we send. Doing so fixes these errors. Cc: stable@vger.kernel.org BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197007 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201981 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703 Signed-off-by: Hans de Goede Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman

platform/x86: hp-wmi: Fix ACPI errors caused by too small buffer

2019-12-04T21:31:08+00:00

commit 16245db1489cd9aa579506f64afeeeb13d825a93 upstream. The HP WMI calls may take up to 128 bytes of data as input, and the AML methods implementing the WMI calls, declare a couple of fields for accessing input in different sizes, specifycally the HWMC method contains: CreateField (Arg1, 0x80, 0x0400, D128) Even though we do not use any of the WMI command-types which need a buffer of this size, the APCI interpreter still tries to create it as it is declared in generoc code at the top of the HWMC method which runs before the code looks at which command-type is requested. This results in many of these errors on many different HP laptop models: [ 14.459261] ACPI Error: Field [D128] at 1152 exceeds Buffer [NULL] size 160 (bits) (20170303/dsopcode-236) [ 14.459268] ACPI Error: Method parse/execution failed [\HWMC] (Node ffff8edcc61507f8), AE_AML_BUFFER_LIMIT (20170303/psparse-543) [ 14.459279] ACPI Error: Method parse/execution failed [\_SB.WMID.WMAA] (Node ffff8edcc61523c0), AE_AML_BUFFER_LIMIT (20170303/psparse-543) This commit increases the size of the data element of the bios_args struct to 128 bytes fixing these errors. Cc: stable@vger.kernel.org BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197007 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201981 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703 Signed-off-by: Hans de Goede Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman

HID: core: check whether Usage Page item is after Usage ID items

2019-12-04T21:31:07+00:00

commit 1cb0d2aee26335d0bccf29100c7bed00ebece851 upstream. Upstream commit 58e75155009c ("HID: core: move Usage Page concatenation to Main item") adds support for Usage Page item after Usage ID items (such as keyboards manufactured by Primax). Usage Page concatenation in Main item works well for following report descriptor patterns: USAGE_PAGE (Keyboard) 05 07 USAGE_MINIMUM (Keyboard LeftControl) 19 E0 USAGE_MAXIMUM (Keyboard Right GUI) 29 E7 LOGICAL_MINIMUM (0) 15 00 LOGICAL_MAXIMUM (1) 25 01 REPORT_SIZE (1) 75 01 REPORT_COUNT (8) 95 08 INPUT (Data,Var,Abs) 81 02 ------------- USAGE_MINIMUM (Keyboard LeftControl) 19 E0 USAGE_MAXIMUM (Keyboard Right GUI) 29 E7 LOGICAL_MINIMUM (0) 15 00 LOGICAL_MAXIMUM (1) 25 01 REPORT_SIZE (1) 75 01 REPORT_COUNT (8) 95 08 USAGE_PAGE (Keyboard) 05 07 INPUT (Data,Var,Abs) 81 02 But it makes the parser act wrong for the following report descriptor pattern(such as some Gamepads): USAGE_PAGE (Button) 05 09 USAGE (Button 1) 09 01 USAGE (Button 2) 09 02 USAGE (Button 4) 09 04 USAGE (Button 5) 09 05 USAGE (Button 7) 09 07 USAGE (Button 8) 09 08 USAGE (Button 14) 09 0E USAGE (Button 15) 09 0F USAGE (Button 13) 09 0D USAGE_PAGE (Consumer Devices) 05 0C USAGE (Back) 0a 24 02 USAGE (HomePage) 0a 23 02 LOGICAL_MINIMUM (0) 15 00 LOGICAL_MAXIMUM (1) 25 01 REPORT_SIZE (1) 75 01 REPORT_COUNT (11) 95 0B INPUT (Data,Var,Abs) 81 02 With Usage Page concatenation in Main item, parser recognizes all the 11 Usages as consumer keys, it is not the HID device's real intention. This patch checks whether Usage Page is really defined after Usage ID items by comparing usage page using status. Usage Page concatenation on currently defined Usage Page will always do in local parsing when Usage ID items encountered. When Main item is parsing, concatenation will do again with last defined Usage Page if this page has not been used in the previous usages concatenation. Signed-off-by: Candle Sun Signed-off-by: Nianfu Bai Cc: Benjamin Tissoires Signed-off-by: Jiri Kosina Cc: Siarhei Vishniakou Signed-off-by: Greg Kroah-Hartman

crypto: talitos - Fix build error by selecting LIB_DES

2019-12-04T21:31:07+00:00

commit dbc2e87bd8b6d3cc79730b3a49c5163b4c386b49 upstream. The talitos driver needs to select LIB_DES as it needs calls des_expand_key. Fixes: 9d574ae8ebc1 ("crypto: talitos/des - switch to new...") Cc: Signed-off-by: Herbert Xu Acked-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

Revert "jffs2: Fix possible null-pointer dereferences in jffs2_add_frag_to_fragtree()"

2019-12-04T21:31:06+00:00

commit 6e78c01fde9023e0701f3af880c1fd9de6e4e8e3 upstream. This reverts commit f2538f999345405f7d2e1194c0c8efa4e11f7b3a. The patch stopped JFFS2 from being able to mount an existing filesystem with the following errors: jffs2: error: (77) jffs2_build_inode_fragtree: Add node to tree failed -22 jffs2: error: (77) jffs2_do_read_inode_internal: Failed to build final fragtree for inode #5377: error -22 Fixes: f2538f999345 ("jffs2: Fix possible null-pointer dereferences...") Cc: stable@vger.kernel.org Suggested-by: Hou Tao Signed-off-by: Joel Stanley Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman

ext4: add more paranoia checking in ext4_expand_extra_isize handling

2019-12-04T21:31:05+00:00

commit 4ea99936a1630f51fc3a2d61a58ec4a1c4b7d55a upstream. It's possible to specify a non-zero s_want_extra_isize via debugging option, and this can cause bad things(tm) to happen when using a file system with an inode size of 128 bytes. Add better checking when the file system is mounted, as well as when we are actually doing the trying to do the inode expansion. Link: https://lore.kernel.org/r/20191110121510.GH23325@mit.edu Reported-by: syzbot+f8d6f8386ceacdbfff57@syzkaller.appspotmail.com Reported-by: syzbot+33d7ea72e47de3bdf4e1@syzkaller.appspotmail.com Reported-by: syzbot+44b6763edfc17144296f@syzkaller.appspotmail.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman

r8169: fix resume on cable plug-in

2019-12-04T21:31:05+00:00

[ Upstream commit 398fd408ccfb5e44b1cbe73a209d2281d3efa83c ] It was reported [0] that network doesn't wake up on cable plug-in with certain chip versions. Reason is that on these chip versions the PHY doesn't detect cable plug-in when being in power-down mode. So prevent the PHY from powering down if WoL is enabled. [0] https://bugzilla.kernel.org/show_bug.cgi?id=202103 Fixes: 95fb8bb3181b ("net: phy: force phy suspend when calling phy_stop") Reported-by: jhdskag3 Tested-by: jhdskag3 Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

r8169: fix jumbo configuration for RTL8168evl

2019-12-04T21:31:04+00:00

[ Upstream commit 14012c9f3bb922b9e0751ba43d15cc580a6049bf ] Alan reported [0] that network is broken since the referenced commit when using jumbo frames. This commit isn't wrong, it just revealed another issue that has been existing before. According to the vendor driver the RTL8168e-specific jumbo config doesn't apply for RTL8168evl. [0] https://lkml.org/lkml/2019/11/30/119 Fixes: 4ebcb113edcc ("r8169: fix jumbo packet handling on resume from suspend") Reported-by: Alan J. Wylie Tested-by: Alan J. Wylie Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

selftests: pmtu: use -oneline for ip route list cache

2019-12-04T21:31:04+00:00

[ Upstream commit 2745aea6750ff0d2c48285d25bdb00e5b636ec8b ] Some versions of iproute2 will output more than one line per entry, which will cause the test to fail, like: TEST: ipv6: list and flush cached exceptions [FAIL] can't list cached exceptions That happens, for example, with iproute2 4.15.0. When using the -oneline option, this will work just fine: TEST: ipv6: list and flush cached exceptions [ OK ] This also works just fine with a more recent version of iproute2, like 5.4.0. For some reason, two lines are printed for the IPv4 test no matter what version of iproute2 is used. Use the same -oneline parameter there instead of counting the lines twice. Fixes: b964641e9925 ("selftests: pmtu: Make list_flush_ipv6_exception test more demanding") Signed-off-by: Thadeu Lima de Souza Cascardo Acked-by: Stefano Brivio Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman