2021-12-27 15:33:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 00/38] 4.19.223-rc1 review

This is the start of the stable review cycle for the 4.19.223 release.
There are 38 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 Wed, 29 Dec 2021 15:13:09 +0000.
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.19.223-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.19.y
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 4.19.223-rc1

Rémi Denis-Courmont <[email protected]>
phonet/pep: refuse to enable an unbound pipe

Lin Ma <[email protected]>
hamradio: improve the incomplete fix to avoid NPD

Lin Ma <[email protected]>
hamradio: defer ax25 kfree after unregister_netdev

Lin Ma <[email protected]>
ax25: NPD bug when detaching AX25 device

Guenter Roeck <[email protected]>
hwmon: (lm90) Do not report 'busy' status bit as alarm

Samuel Čavoj <[email protected]>
Input: i8042 - enable deferred probe quirk for ASUS UM325UA

Sean Christopherson <[email protected]>
KVM: VMX: Fix stale docs for kvm-intel.emulate_invalid_guest_state

Marian Postevca <[email protected]>
usb: gadget: u_ether: fix race in setting MAC address in setup phase

Chao Yu <[email protected]>
f2fs: fix to do sanity check on last xattr entry in __f2fs_setxattr()

Ard Biesheuvel <[email protected]>
ARM: 9169/1: entry: fix Thumb2 bug in iWMMXt exception handling

Fabien Dessenne <[email protected]>
pinctrl: stm32: consider the GPIO offset to expose all the GPIO lines

Andrew Cooper <[email protected]>
x86/pkey: Fix undefined behaviour with PKRU_WD_BIT

John David Anglin <[email protected]>
parisc: Correct completer in lws start

Thadeu Lima de Souza Cascardo <[email protected]>
ipmi: fix initialization when workqueue allocation fails

Thadeu Lima de Souza Cascardo <[email protected]>
ipmi: bail out if init_srcu_struct fails

José Expósito <[email protected]>
Input: atmel_mxt_ts - fix double free in mxt_read_info_block

Colin Ian King <[email protected]>
ALSA: drivers: opl3: Fix incorrect use of vp->state

Xiaoke Wang <[email protected]>
ALSA: jack: Check the return value of kstrdup()

Guenter Roeck <[email protected]>
hwmon: (lm90) Fix usage of CONFIG2 register in detect function

Jiasheng Jiang <[email protected]>
sfc: falcon: Check null pointer of rx_queue->page_ring

Jiasheng Jiang <[email protected]>
drivers: net: smc911x: Check for error irq

Jiasheng Jiang <[email protected]>
fjes: Check for error irq

Fernando Fernandez Mancera <[email protected]>
bonding: fix ad_actor_system option setting to default

Wu Bo <[email protected]>
ipmi: Fix UAF when uninstall ipmi_si and ipmi_msghandler module

Willem de Bruijn <[email protected]>
net: skip virtio_net_hdr_set_proto if protocol already set

Willem de Bruijn <[email protected]>
net: accept UFOv6 packages in virtio_net_hdr_to_skb

Jiasheng Jiang <[email protected]>
qlcnic: potential dereference null pointer of rx_queue->page_ring

Ignacy Gawędzki <[email protected]>
netfilter: fix regression in looped (broad|multi)cast's MAC handling

José Expósito <[email protected]>
IB/qib: Fix memory leak in qib_user_sdma_queue_pkts()

Dongliang Mu <[email protected]>
spi: change clk_disable_unprepare to clk_unprepare

Robert Marko <[email protected]>
arm64: dts: allwinner: orangepi-zero-plus: fix PHY mode

Benjamin Tissoires <[email protected]>
HID: holtek: fix mouse probing

Paolo Valente <[email protected]>
block, bfq: fix use after free in bfq_bfqq_expire

Paolo Valente <[email protected]>
block, bfq: fix queue removal from weights tree

Paolo Valente <[email protected]>
block, bfq: fix decrement of num_active_groups

Federico Motta <[email protected]>
block, bfq: fix asymmetric scenarios detection

Federico Motta <[email protected]>
block, bfq: improve asymmetric scenarios detection

Greg Jesionowski <[email protected]>
net: usb: lan78xx: add Allied Telesis AT29M2-AF


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

Diffstat:

Documentation/admin-guide/kernel-parameters.txt | 8 +-
Documentation/networking/bonding.txt | 11 +-
Makefile | 4 +-
arch/arm/kernel/entry-armv.S | 8 +-
.../dts/allwinner/sun50i-h5-orangepi-zero-plus.dts | 2 +-
arch/parisc/kernel/syscall.S | 2 +-
arch/x86/include/asm/pgtable.h | 4 +-
block/bfq-iosched.c | 287 +++++++++++++--------
block/bfq-iosched.h | 76 ++++--
block/bfq-wf2q.c | 56 ++--
drivers/char/ipmi/ipmi_msghandler.c | 21 +-
drivers/hid/hid-holtek-mouse.c | 15 ++
drivers/hwmon/lm90.c | 8 +-
drivers/infiniband/hw/qib/qib_user_sdma.c | 2 +-
drivers/input/serio/i8042-x86ia64io.h | 7 +
drivers/input/touchscreen/atmel_mxt_ts.c | 2 +-
drivers/net/bonding/bond_options.c | 2 +-
drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov.h | 2 +-
.../ethernet/qlogic/qlcnic/qlcnic_sriov_common.c | 12 +-
.../net/ethernet/qlogic/qlcnic/qlcnic_sriov_pf.c | 4 +-
drivers/net/ethernet/sfc/falcon/rx.c | 5 +-
drivers/net/ethernet/smsc/smc911x.c | 5 +
drivers/net/fjes/fjes_main.c | 5 +
drivers/net/hamradio/mkiss.c | 5 +-
drivers/net/usb/lan78xx.c | 6 +
drivers/pinctrl/stm32/pinctrl-stm32.c | 8 +-
drivers/spi/spi-armada-3700.c | 2 +-
drivers/usb/gadget/function/u_ether.c | 15 +-
fs/f2fs/xattr.c | 9 +-
include/linux/virtio_net.h | 25 +-
net/ax25/af_ax25.c | 4 +-
net/netfilter/nfnetlink_log.c | 3 +-
net/netfilter/nfnetlink_queue.c | 3 +-
net/phonet/pep.c | 2 +
sound/core/jack.c | 4 +
sound/drivers/opl3/opl3_midi.c | 2 +-
36 files changed, 424 insertions(+), 212 deletions(-)




2021-12-27 15:33:25

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 09/38] spi: change clk_disable_unprepare to clk_unprepare

From: Dongliang Mu <[email protected]>

[ Upstream commit db6689b643d8653092f5853751ea2cdbc299f8d3 ]

The corresponding API for clk_prepare is clk_unprepare, other than
clk_disable_unprepare.

Fix this by changing clk_disable_unprepare to clk_unprepare.

Fixes: 5762ab71eb24 ("spi: Add support for Armada 3700 SPI Controller")
Signed-off-by: Dongliang Mu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/spi/spi-armada-3700.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-armada-3700.c b/drivers/spi/spi-armada-3700.c
index 7dcb14d303eb4..d8715954f4e08 100644
--- a/drivers/spi/spi-armada-3700.c
+++ b/drivers/spi/spi-armada-3700.c
@@ -912,7 +912,7 @@ static int a3700_spi_probe(struct platform_device *pdev)
return 0;

error_clk:
- clk_disable_unprepare(spi->clk);
+ clk_unprepare(spi->clk);
error:
spi_master_put(master);
out:
--
2.34.1




2021-12-27 15:33:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 15/38] ipmi: Fix UAF when uninstall ipmi_si and ipmi_msghandler module

From: Wu Bo <[email protected]>

[ Upstream commit ffb76a86f8096a8206be03b14adda6092e18e275 ]

Hi,

When testing install and uninstall of ipmi_si.ko and ipmi_msghandler.ko,
the system crashed.

The log as follows:
[ 141.087026] BUG: unable to handle kernel paging request at ffffffffc09b3a5a
[ 141.087241] PGD 8fe4c0d067 P4D 8fe4c0d067 PUD 8fe4c0f067 PMD 103ad89067 PTE 0
[ 141.087464] Oops: 0010 [#1] SMP NOPTI
[ 141.087580] CPU: 67 PID: 668 Comm: kworker/67:1 Kdump: loaded Not tainted 4.18.0.x86_64 #47
[ 141.088009] Workqueue: events 0xffffffffc09b3a40
[ 141.088009] RIP: 0010:0xffffffffc09b3a5a
[ 141.088009] Code: Bad RIP value.
[ 141.088009] RSP: 0018:ffffb9094e2c3e88 EFLAGS: 00010246
[ 141.088009] RAX: 0000000000000000 RBX: ffff9abfdb1f04a0 RCX: 0000000000000000
[ 141.088009] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
[ 141.088009] RBP: 0000000000000000 R08: ffff9abfffee3cb8 R09: 00000000000002e1
[ 141.088009] R10: ffffb9094cb73d90 R11: 00000000000f4240 R12: ffff9abfffee8700
[ 141.088009] R13: 0000000000000000 R14: ffff9abfdb1f04a0 R15: ffff9abfdb1f04a8
[ 141.088009] FS: 0000000000000000(0000) GS:ffff9abfffec0000(0000) knlGS:0000000000000000
[ 141.088009] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 141.088009] CR2: ffffffffc09b3a30 CR3: 0000008fe4c0a001 CR4: 00000000007606e0
[ 141.088009] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 141.088009] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 141.088009] PKRU: 55555554
[ 141.088009] Call Trace:
[ 141.088009] ? process_one_work+0x195/0x390
[ 141.088009] ? worker_thread+0x30/0x390
[ 141.088009] ? process_one_work+0x390/0x390
[ 141.088009] ? kthread+0x10d/0x130
[ 141.088009] ? kthread_flush_work_fn+0x10/0x10
[ 141.088009] ? ret_from_fork+0x35/0x40] BUG: unable to handle kernel paging request at ffffffffc0b28a5a
[ 200.223240] PGD 97fe00d067 P4D 97fe00d067 PUD 97fe00f067 PMD a580cbf067 PTE 0
[ 200.223464] Oops: 0010 [#1] SMP NOPTI
[ 200.223579] CPU: 63 PID: 664 Comm: kworker/63:1 Kdump: loaded Not tainted 4.18.0.x86_64 #46
[ 200.224008] Workqueue: events 0xffffffffc0b28a40
[ 200.224008] RIP: 0010:0xffffffffc0b28a5a
[ 200.224008] Code: Bad RIP value.
[ 200.224008] RSP: 0018:ffffbf3c8e2a3e88 EFLAGS: 00010246
[ 200.224008] RAX: 0000000000000000 RBX: ffffa0799ad6bca0 RCX: 0000000000000000
[ 200.224008] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246
[ 200.224008] RBP: 0000000000000000 R08: ffff9fe43fde3cb8 R09: 00000000000000d5
[ 200.224008] R10: ffffbf3c8cb53d90 R11: 00000000000f4240 R12: ffff9fe43fde8700
[ 200.224008] R13: 0000000000000000 R14: ffffa0799ad6bca0 R15: ffffa0799ad6bca8
[ 200.224008] FS: 0000000000000000(0000) GS:ffff9fe43fdc0000(0000) knlGS:0000000000000000
[ 200.224008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 200.224008] CR2: ffffffffc0b28a30 CR3: 00000097fe00a002 CR4: 00000000007606e0
[ 200.224008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 200.224008] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 200.224008] PKRU: 55555554
[ 200.224008] Call Trace:
[ 200.224008] ? process_one_work+0x195/0x390
[ 200.224008] ? worker_thread+0x30/0x390
[ 200.224008] ? process_one_work+0x390/0x390
[ 200.224008] ? kthread+0x10d/0x130
[ 200.224008] ? kthread_flush_work_fn+0x10/0x10
[ 200.224008] ? ret_from_fork+0x35/0x40
[ 200.224008] kernel fault(0x1) notification starting on CPU 63
[ 200.224008] kernel fault(0x1) notification finished on CPU 63
[ 200.224008] CR2: ffffffffc0b28a5a
[ 200.224008] ---[ end trace c82a412d93f57412 ]---

The reason is as follows:
T1: rmmod ipmi_si.
->ipmi_unregister_smi()
-> ipmi_bmc_unregister()
-> __ipmi_bmc_unregister()
-> kref_put(&bmc->usecount, cleanup_bmc_device);
-> schedule_work(&bmc->remove_work);

T2: rmmod ipmi_msghandler.
ipmi_msghander module uninstalled, and the module space
will be freed.

T3: bmc->remove_work doing cleanup the bmc resource.
-> cleanup_bmc_work()
-> platform_device_unregister(&bmc->pdev);
-> platform_device_del(pdev);
-> device_del(&pdev->dev);
-> kobject_uevent(&dev->kobj, KOBJ_REMOVE);
-> kobject_uevent_env()
-> dev_uevent()
-> if (dev->type && dev->type->name)

'dev->type'(bmc_device_type) pointer space has freed when uninstall
ipmi_msghander module, 'dev->type->name' cause the system crash.

drivers/char/ipmi/ipmi_msghandler.c:
2820 static const struct device_type bmc_device_type = {
2821 .groups = bmc_dev_attr_groups,
2822 };

Steps to reproduce:
Add a time delay in cleanup_bmc_work() function,
and uninstall ipmi_si and ipmi_msghandler module.

2910 static void cleanup_bmc_work(struct work_struct *work)
2911 {
2912 struct bmc_device *bmc = container_of(work, struct bmc_device,
2913 remove_work);
2914 int id = bmc->pdev.id; /* Unregister overwrites id */
2915
2916 msleep(3000); <---
2917 platform_device_unregister(&bmc->pdev);
2918 ida_simple_remove(&ipmi_bmc_ida, id);
2919 }

Use 'remove_work_wq' instead of 'system_wq' to solve this issues.

Fixes: b2cfd8ab4add ("ipmi: Rework device id and guid handling to catch changing BMCs")
Signed-off-by: Wu Bo <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Corey Minyard <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/char/ipmi/ipmi_msghandler.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c
index 48929df7673b1..6db709e2c34b1 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -2863,7 +2863,7 @@ cleanup_bmc_device(struct kref *ref)
* with removing the device attributes while reading a device
* attribute.
*/
- schedule_work(&bmc->remove_work);
+ queue_work(remove_work_wq, &bmc->remove_work);
}

/*
--
2.34.1




2021-12-27 15:33:42

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 25/38] ipmi: fix initialization when workqueue allocation fails

From: Thadeu Lima de Souza Cascardo <[email protected]>

commit 75d70d76cb7b927cace2cb34265d68ebb3306b13 upstream.

If the workqueue allocation fails, the driver is marked as not initialized,
and timer and panic_notifier will be left registered.

Instead of removing those when workqueue allocation fails, do the workqueue
initialization before doing it, and cleanup srcu_struct if it fails.

Fixes: 1d49eb91e86e ("ipmi: Move remove_work to dedicated workqueue")
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Cc: Corey Minyard <[email protected]>
Cc: Ioanna Alifieraki <[email protected]>
Cc: [email protected]
Message-Id: <[email protected]>
Signed-off-by: Corey Minyard <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/char/ipmi/ipmi_msghandler.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)

--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -5089,20 +5089,23 @@ static int ipmi_init_msghandler(void)
if (rv)
goto out;

- timer_setup(&ipmi_timer, ipmi_timeout, 0);
- mod_timer(&ipmi_timer, jiffies + IPMI_TIMEOUT_JIFFIES);
-
- atomic_notifier_chain_register(&panic_notifier_list, &panic_block);
-
remove_work_wq = create_singlethread_workqueue("ipmi-msghandler-remove-wq");
if (!remove_work_wq) {
pr_err("unable to create ipmi-msghandler-remove-wq workqueue");
rv = -ENOMEM;
- goto out;
+ goto out_wq;
}

+ timer_setup(&ipmi_timer, ipmi_timeout, 0);
+ mod_timer(&ipmi_timer, jiffies + IPMI_TIMEOUT_JIFFIES);
+
+ atomic_notifier_chain_register(&panic_notifier_list, &panic_block);
+
initialized = true;

+out_wq:
+ if (rv)
+ cleanup_srcu_struct(&ipmi_interfaces_srcu);
out:
mutex_unlock(&ipmi_interfaces_mutex);
return rv;



2021-12-27 15:33:44

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 26/38] parisc: Correct completer in lws start

From: John David Anglin <[email protected]>

commit 8f66fce0f46560b9e910787ff7ad0974441c4f9c upstream.

The completer in the "or,ev %r1,%r30,%r30" instruction is reversed, so we are
not clipping the LWS number when we are called from a 32-bit process (W=0).
We need to nulify the following depdi instruction when the least-significant
bit of %r30 is 1.

If the %r20 register is not clipped, a user process could perform a LWS call
that would branch to an undefined location in the kernel and potentially crash
the machine.

Signed-off-by: John David Anglin <[email protected]>
Cc: [email protected] # 4.19+
Signed-off-by: Helge Deller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/parisc/kernel/syscall.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/parisc/kernel/syscall.S
+++ b/arch/parisc/kernel/syscall.S
@@ -478,7 +478,7 @@ lws_start:
extrd,u %r1,PSW_W_BIT,1,%r1
/* sp must be aligned on 4, so deposit the W bit setting into
* the bottom of sp temporarily */
- or,ev %r1,%r30,%r30
+ or,od %r1,%r30,%r30

/* Clip LWS number to a 32-bit value for 32-bit processes */
depdi 0, 31, 32, %r20



2021-12-27 15:33:46

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 24/38] ipmi: bail out if init_srcu_struct fails

From: Thadeu Lima de Souza Cascardo <[email protected]>

commit 2b5160b12091285c5aca45980f100a9294af7b04 upstream.

In case, init_srcu_struct fails (because of memory allocation failure), we
might proceed with the driver initialization despite srcu_struct not being
entirely initialized.

Fixes: 913a89f009d9 ("ipmi: Don't initialize anything in the core until something uses it")
Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]>
Cc: Corey Minyard <[email protected]>
Cc: [email protected]
Message-Id: <[email protected]>
Signed-off-by: Corey Minyard <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/char/ipmi/ipmi_msghandler.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -5085,7 +5085,9 @@ static int ipmi_init_msghandler(void)
if (initialized)
goto out;

- init_srcu_struct(&ipmi_interfaces_srcu);
+ rv = init_srcu_struct(&ipmi_interfaces_srcu);
+ if (rv)
+ goto out;

timer_setup(&ipmi_timer, ipmi_timeout, 0);
mod_timer(&ipmi_timer, jiffies + IPMI_TIMEOUT_JIFFIES);



2021-12-27 15:33:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 27/38] x86/pkey: Fix undefined behaviour with PKRU_WD_BIT

From: Andrew Cooper <[email protected]>

commit 57690554abe135fee81d6ac33cc94d75a7e224bb upstream.

Both __pkru_allows_write() and arch_set_user_pkey_access() shift
PKRU_WD_BIT (a signed constant) by up to 30 bits, hitting the
sign bit.

Use unsigned constants instead.

Clearly pkey 15 has not been used in combination with UBSAN yet.

Noticed by code inspection only. I can't actually provoke the
compiler into generating incorrect logic as far as this shift is
concerned.

[
dhansen: add stable@ tag, plus minor changelog massaging,

For anyone doing backports, these #defines were in
arch/x86/include/asm/pgtable.h before 784a46618f6.
]

Fixes: 33a709b25a76 ("mm/gup, x86/mm/pkeys: Check VMAs and PTEs for protection keys")
Signed-off-by: Andrew Cooper <[email protected]>
Signed-off-by: Dave Hansen <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/include/asm/pgtable.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -1356,8 +1356,8 @@ static inline pmd_t pmd_swp_clear_soft_d
#endif
#endif

-#define PKRU_AD_BIT 0x1
-#define PKRU_WD_BIT 0x2
+#define PKRU_AD_BIT 0x1u
+#define PKRU_WD_BIT 0x2u
#define PKRU_BITS_PER_PKEY 2

static inline bool __pkru_allows_read(u32 pkru, u16 pkey)



2021-12-27 15:33:54

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 28/38] pinctrl: stm32: consider the GPIO offset to expose all the GPIO lines

From: Fabien Dessenne <[email protected]>

commit b67210cc217f9ca1c576909454d846970c13dfd4 upstream.

Consider the GPIO controller offset (from "gpio-ranges") to compute the
maximum GPIO line number.
This fixes an issue where gpio-ranges uses a non-null offset.
e.g.: gpio-ranges = <&pinctrl 6 86 10>
In that case the last valid GPIO line is not 9 but 15 (6 + 10 - 1)

Cc: [email protected]
Fixes: 67e2996f72c7 ("pinctrl: stm32: fix the reported number of GPIO lines per bank")
Reported-by: Christoph Fritz <[email protected]>
Signed-off-by: Fabien Dessenne <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/pinctrl/stm32/pinctrl-stm32.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -1011,10 +1011,10 @@ static int stm32_gpiolib_register_bank(s
bank_nr = args.args[1] / STM32_GPIO_PINS_PER_BANK;
bank->gpio_chip.base = args.args[1];

- npins = args.args[2];
- while (!of_parse_phandle_with_fixed_args(np, "gpio-ranges", 3,
- ++i, &args))
- npins += args.args[2];
+ /* get the last defined gpio line (offset + nb of pins) */
+ npins = args.args[0] + args.args[2];
+ while (!of_parse_phandle_with_fixed_args(np, "gpio-ranges", 3, ++i, &args))
+ npins = max(npins, (int)(args.args[0] + args.args[2]));
} else {
bank_nr = pctl->nbanks;
bank->gpio_chip.base = bank_nr * STM32_GPIO_PINS_PER_BANK;



2021-12-27 15:33:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 29/38] ARM: 9169/1: entry: fix Thumb2 bug in iWMMXt exception handling

From: Ard Biesheuvel <[email protected]>

commit 8536a5ef886005bc443c2da9b842d69fd3d7647f upstream.

The Thumb2 version of the FP exception handling entry code treats the
register holding the CP number (R8) differently, resulting in the iWMMXT
CP number check to be incorrect.

Fix this by unifying the ARM and Thumb2 code paths, and switch the
order of the additions of the TI_USED_CP offset and the shifted CP
index.

Cc: <[email protected]>
Fixes: b86040a59feb ("Thumb-2: Implementation of the unified start-up and exceptions code")
Signed-off-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/kernel/entry-armv.S | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)

--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -620,11 +620,9 @@ call_fpe:
tstne r0, #0x04000000 @ bit 26 set on both ARM and Thumb-2
reteq lr
and r8, r0, #0x00000f00 @ mask out CP number
- THUMB( lsr r8, r8, #8 )
mov r7, #1
- add r6, r10, #TI_USED_CP
- ARM( strb r7, [r6, r8, lsr #8] ) @ set appropriate used_cp[]
- THUMB( strb r7, [r6, r8] ) @ set appropriate used_cp[]
+ add r6, r10, r8, lsr #8 @ add used_cp[] array offset first
+ strb r7, [r6, #TI_USED_CP] @ set appropriate used_cp[]
#ifdef CONFIG_IWMMXT
@ Test if we need to give access to iWMMXt coprocessors
ldr r5, [r10, #TI_FLAGS]
@@ -633,7 +631,7 @@ call_fpe:
bcs iwmmxt_task_enable
#endif
ARM( add pc, pc, r8, lsr #6 )
- THUMB( lsl r8, r8, #2 )
+ THUMB( lsr r8, r8, #6 )
THUMB( add pc, r8 )
nop




2021-12-27 15:34:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 32/38] KVM: VMX: Fix stale docs for kvm-intel.emulate_invalid_guest_state

From: Sean Christopherson <[email protected]>

commit 0ff29701ffad9a5d5a24344d8b09f3af7b96ffda upstream.

Update the documentation for kvm-intel's emulate_invalid_guest_state to
rectify the description of KVM's default behavior, and to document that
the behavior and thus parameter only applies to L1.

Fixes: a27685c33acc ("KVM: VMX: Emulate invalid guest state by default")
Signed-off-by: Sean Christopherson <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Maxim Levitsky <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
Documentation/admin-guide/kernel-parameters.txt | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2019,8 +2019,12 @@
Default is 1 (enabled)

kvm-intel.emulate_invalid_guest_state=
- [KVM,Intel] Enable emulation of invalid guest states
- Default is 0 (disabled)
+ [KVM,Intel] Disable emulation of invalid guest state.
+ Ignored if kvm-intel.enable_unrestricted_guest=1, as
+ guest state is never invalid for unrestricted guests.
+ This param doesn't apply to nested guests (L2), as KVM
+ never emulates invalid L2 guest state.
+ Default is 1 (enabled)

kvm-intel.flexpriority=
[KVM,Intel] Disable FlexPriority feature (TPR shadow).



2021-12-27 15:34:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 16/38] bonding: fix ad_actor_system option setting to default

From: Fernando Fernandez Mancera <[email protected]>

[ Upstream commit 1c15b05baea71a5ff98235783e3e4ad227760876 ]

When 802.3ad bond mode is configured the ad_actor_system option is set to
"00:00:00:00:00:00". But when trying to set the all-zeroes MAC as actors'
system address it was failing with EINVAL.

An all-zeroes ethernet address is valid, only multicast addresses are not
valid values.

Fixes: 171a42c38c6e ("bonding: add netlink support for sys prio, actor sys mac, and port key")
Signed-off-by: Fernando Fernandez Mancera <[email protected]>
Acked-by: Jay Vosburgh <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
Documentation/networking/bonding.txt | 11 ++++++-----
drivers/net/bonding/bond_options.c | 2 +-
2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index d3e5dd26db12d..4035a495c0606 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -191,11 +191,12 @@ ad_actor_sys_prio
ad_actor_system

In an AD system, this specifies the mac-address for the actor in
- protocol packet exchanges (LACPDUs). The value cannot be NULL or
- multicast. It is preferred to have the local-admin bit set for this
- mac but driver does not enforce it. If the value is not given then
- system defaults to using the masters' mac address as actors' system
- address.
+ protocol packet exchanges (LACPDUs). The value cannot be a multicast
+ address. If the all-zeroes MAC is specified, bonding will internally
+ use the MAC of the bond itself. It is preferred to have the
+ local-admin bit set for this mac but driver does not enforce it. If
+ the value is not given then system defaults to using the masters'
+ mac address as actors' system address.

This parameter has effect only in 802.3ad mode and is available through
SysFs interface.
diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c
index 80867bd8f44c3..c9aa28eee191d 100644
--- a/drivers/net/bonding/bond_options.c
+++ b/drivers/net/bonding/bond_options.c
@@ -1439,7 +1439,7 @@ static int bond_option_ad_actor_system_set(struct bonding *bond,
mac = (u8 *)&newval->value;
}

- if (!is_valid_ether_addr(mac))
+ if (is_multicast_ether_addr(mac))
goto err;

netdev_dbg(bond->dev, "Setting ad_actor_system to %pM\n", mac);
--
2.34.1




2021-12-27 15:34:06

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 33/38] Input: i8042 - enable deferred probe quirk for ASUS UM325UA

From: Samuel Čavoj <[email protected]>

commit 44ee250aeeabb28b52a10397ac17ffb8bfe94839 upstream.

The ASUS UM325UA suffers from the same issue as the ASUS UX425UA, which
is a very similar laptop. The i8042 device is not usable immediately
after boot and fails to initialize, requiring a deferred retry.

Enable the deferred probe quirk for the UM325UA.

BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1190256
Signed-off-by: Samuel Čavoj <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/input/serio/i8042-x86ia64io.h | 7 +++++++
1 file changed, 7 insertions(+)

--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -996,6 +996,13 @@ static const struct dmi_system_id __init
DMI_MATCH(DMI_PRODUCT_NAME, "C504"),
},
},
+ {
+ /* ASUS ZenBook UM325UA */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "ZenBook UX325UA_UM325UA"),
+ },
+ },
{ }
};




2021-12-27 15:34:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 31/38] usb: gadget: u_ether: fix race in setting MAC address in setup phase

From: Marian Postevca <[email protected]>

commit 890d5b40908bfd1a79be018d2d297cf9df60f4ee upstream.

When listening for notifications through netlink of a new interface being
registered, sporadically, it is possible for the MAC to be read as zero.
The zero MAC address lasts a short period of time and then switches to a
valid random MAC address.

This causes problems for netd in Android, which assumes that the interface
is malfunctioning and will not use it.

In the good case we get this log:
InterfaceController::getCfg() ifName usb0
hwAddr 92:a8:f0:73:79:5b ipv4Addr 0.0.0.0 flags 0x1002

In the error case we get these logs:
InterfaceController::getCfg() ifName usb0
hwAddr 00:00:00:00:00:00 ipv4Addr 0.0.0.0 flags 0x1002

netd : interfaceGetCfg("usb0")
netd : interfaceSetCfg() -> ServiceSpecificException
(99, "[Cannot assign requested address] : ioctl() failed")

The reason for the issue is the order in which the interface is setup,
it is first registered through register_netdev() and after the MAC
address is set.

Fixed by first setting the MAC address of the net_device and after that
calling register_netdev().

Fixes: bcd4a1c40bee885e ("usb: gadget: u_ether: construct with default values and add setters/getters")
Cc: [email protected]
Signed-off-by: Marian Postevca <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/gadget/function/u_ether.c | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)

--- a/drivers/usb/gadget/function/u_ether.c
+++ b/drivers/usb/gadget/function/u_ether.c
@@ -860,19 +860,23 @@ int gether_register_netdev(struct net_de
{
struct eth_dev *dev;
struct usb_gadget *g;
- struct sockaddr sa;
int status;

if (!net->dev.parent)
return -EINVAL;
dev = netdev_priv(net);
g = dev->gadget;
+
+ memcpy(net->dev_addr, dev->dev_mac, ETH_ALEN);
+ net->addr_assign_type = NET_ADDR_RANDOM;
+
status = register_netdev(net);
if (status < 0) {
dev_dbg(&g->dev, "register_netdev failed, %d\n", status);
return status;
} else {
INFO(dev, "HOST MAC %pM\n", dev->host_mac);
+ INFO(dev, "MAC %pM\n", dev->dev_mac);

/* two kinds of host-initiated state changes:
* - iff DATA transfer is active, carrier is "on"
@@ -880,15 +884,6 @@ int gether_register_netdev(struct net_de
*/
netif_carrier_off(net);
}
- sa.sa_family = net->type;
- memcpy(sa.sa_data, dev->dev_mac, ETH_ALEN);
- rtnl_lock();
- status = dev_set_mac_address(net, &sa);
- rtnl_unlock();
- if (status)
- pr_warn("cannot set self ethernet address: %d\n", status);
- else
- INFO(dev, "MAC %pM\n", dev->dev_mac);

return status;
}



2021-12-27 15:34:09

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 30/38] f2fs: fix to do sanity check on last xattr entry in __f2fs_setxattr()

From: Chao Yu <[email protected]>

commit 5598b24efaf4892741c798b425d543e4bed357a1 upstream.

As Wenqing Liu reported in bugzilla:

https://bugzilla.kernel.org/show_bug.cgi?id=215235

- Overview
page fault in f2fs_setxattr() when mount and operate on corrupted image

- Reproduce
tested on kernel 5.16-rc3, 5.15.X under root

1. unzip tmp7.zip
2. ./single.sh f2fs 7

Sometimes need to run the script several times

- Kernel dump
loop0: detected capacity change from 0 to 131072
F2FS-fs (loop0): Found nat_bits in checkpoint
F2FS-fs (loop0): Mounted with checkpoint version = 7548c2ee
BUG: unable to handle page fault for address: ffffe47bc7123f48
RIP: 0010:kfree+0x66/0x320
Call Trace:
__f2fs_setxattr+0x2aa/0xc00 [f2fs]
f2fs_setxattr+0xfa/0x480 [f2fs]
__f2fs_set_acl+0x19b/0x330 [f2fs]
__vfs_removexattr+0x52/0x70
__vfs_removexattr_locked+0xb1/0x140
vfs_removexattr+0x56/0x100
removexattr+0x57/0x80
path_removexattr+0xa3/0xc0
__x64_sys_removexattr+0x17/0x20
do_syscall_64+0x37/0xb0
entry_SYSCALL_64_after_hwframe+0x44/0xae

The root cause is in __f2fs_setxattr(), we missed to do sanity check on
last xattr entry, result in out-of-bound memory access during updating
inconsistent xattr data of target inode.

After the fix, it can detect such xattr inconsistency as below:

F2FS-fs (loop11): inode (7) has invalid last xattr entry, entry_size: 60676
F2FS-fs (loop11): inode (8) has corrupted xattr
F2FS-fs (loop11): inode (8) has corrupted xattr
F2FS-fs (loop11): inode (8) has invalid last xattr entry, entry_size: 47736

Cc: [email protected]
Reported-by: Wenqing Liu <[email protected]>
Signed-off-by: Chao Yu <[email protected]>
Signed-off-by: Jaegeuk Kim <[email protected]>
[delete f2fs_err() call as it's not in older kernels - gregkh]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/f2fs/xattr.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)

--- a/fs/f2fs/xattr.c
+++ b/fs/f2fs/xattr.c
@@ -658,8 +658,15 @@ static int __f2fs_setxattr(struct inode
}

last = here;
- while (!IS_XATTR_LAST_ENTRY(last))
+ while (!IS_XATTR_LAST_ENTRY(last)) {
+ if ((void *)(last) + sizeof(__u32) > last_base_addr ||
+ (void *)XATTR_NEXT_ENTRY(last) > last_base_addr) {
+ set_sbi_flag(F2FS_I_SB(inode), SBI_NEED_FSCK);
+ error = -EFSCORRUPTED;
+ goto exit;
+ }
last = XATTR_NEXT_ENTRY(last);
+ }

newsize = XATTR_ALIGN(sizeof(struct f2fs_xattr_entry) + len + size);




2021-12-27 15:34:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 34/38] hwmon: (lm90) Do not report busy status bit as alarm

From: Guenter Roeck <[email protected]>

commit cdc5287acad9ede121924a9c9313544b80d15842 upstream.

Bit 7 of the status register indicates that the chip is busy
doing a conversion. It does not indicate an alarm status.
Stop reporting it as alarm status bit.

Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hwmon/lm90.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -197,6 +197,7 @@ enum chips { lm90, adm1032, lm99, lm86,
#define LM90_STATUS_RHIGH (1 << 4) /* remote high temp limit tripped */
#define LM90_STATUS_LLOW (1 << 5) /* local low temp limit tripped */
#define LM90_STATUS_LHIGH (1 << 6) /* local high temp limit tripped */
+#define LM90_STATUS_BUSY (1 << 7) /* conversion is ongoing */

#define MAX6696_STATUS2_R2THRM (1 << 1) /* remote2 THERM limit tripped */
#define MAX6696_STATUS2_R2OPEN (1 << 2) /* remote2 is an open circuit */
@@ -786,7 +787,7 @@ static int lm90_update_device(struct dev
val = lm90_read_reg(client, LM90_REG_R_STATUS);
if (val < 0)
return val;
- data->alarms = val; /* lower 8 bit of alarms */
+ data->alarms = val & ~LM90_STATUS_BUSY;

if (data->kind == max6696) {
val = lm90_select_remote_channel(client, data, 1);



2021-12-27 15:34:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 35/38] ax25: NPD bug when detaching AX25 device

From: Lin Ma <[email protected]>

commit 1ade48d0c27d5da1ccf4b583d8c5fc8b534a3ac8 upstream.

The existing cleanup routine implementation is not well synchronized
with the syscall routine. When a device is detaching, below race could
occur.

static int ax25_sendmsg(...) {
...
lock_sock()
ax25 = sk_to_ax25(sk);
if (ax25->ax25_dev == NULL) // CHECK
...
ax25_queue_xmit(skb, ax25->ax25_dev->dev); // USE
...
}

static void ax25_kill_by_device(...) {
...
if (s->ax25_dev == ax25_dev) {
s->ax25_dev = NULL;
...
}

Other syscall functions like ax25_getsockopt, ax25_getname,
ax25_info_show also suffer from similar races. To fix them, this patch
introduce lock_sock() into ax25_kill_by_device in order to guarantee
that the nullify action in cleanup routine cannot proceed when another
socket request is pending.

Signed-off-by: Hanjie Wu <[email protected]>
Signed-off-by: Lin Ma <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ax25/af_ax25.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -88,8 +88,10 @@ static void ax25_kill_by_device(struct n
again:
ax25_for_each(s, &ax25_list) {
if (s->ax25_dev == ax25_dev) {
- s->ax25_dev = NULL;
spin_unlock_bh(&ax25_list_lock);
+ lock_sock(s->sk);
+ s->ax25_dev = NULL;
+ release_sock(s->sk);
ax25_disconnect(s, ENETUNREACH);
spin_lock_bh(&ax25_list_lock);




2021-12-27 15:34:21

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 36/38] hamradio: defer ax25 kfree after unregister_netdev

From: Lin Ma <[email protected]>

commit 3e0588c291d6ce225f2b891753ca41d45ba42469 upstream.

There is a possible race condition (use-after-free) like below

(USE) | (FREE)
ax25_sendmsg |
ax25_queue_xmit |
dev_queue_xmit |
__dev_queue_xmit |
__dev_xmit_skb |
sch_direct_xmit | ...
xmit_one |
netdev_start_xmit | tty_ldisc_kill
__netdev_start_xmit | mkiss_close
ax_xmit | kfree
ax_encaps |
|

Even though there are two synchronization primitives before the kfree:
1. wait_for_completion(&ax->dead). This can prevent the race with
routines from mkiss_ioctl. However, it cannot stop the routine coming
from upper layer, i.e., the ax25_sendmsg.

2. netif_stop_queue(ax->dev). It seems that this line of code aims to
halt the transmit queue but it fails to stop the routine that already
being xmit.

This patch reorder the kfree after the unregister_netdev to avoid the
possible UAF as the unregister_netdev() is well synchronized and won't
return if there is a running routine.

Signed-off-by: Lin Ma <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/hamradio/mkiss.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

--- a/drivers/net/hamradio/mkiss.c
+++ b/drivers/net/hamradio/mkiss.c
@@ -803,13 +803,14 @@ static void mkiss_close(struct tty_struc
*/
netif_stop_queue(ax->dev);

- /* Free all AX25 frame buffers. */
- kfree(ax->rbuff);
- kfree(ax->xbuff);
-
ax->tty = NULL;

unregister_netdev(ax->dev);
+
+ /* Free all AX25 frame buffers after unreg. */
+ kfree(ax->rbuff);
+ kfree(ax->xbuff);
+
free_netdev(ax->dev);
}




2021-12-27 15:34:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 37/38] hamradio: improve the incomplete fix to avoid NPD

From: Lin Ma <[email protected]>

commit b2f37aead1b82a770c48b5d583f35ec22aabb61e upstream.

The previous commit 3e0588c291d6 ("hamradio: defer ax25 kfree after
unregister_netdev") reorder the kfree operations and unregister_netdev
operation to prevent UAF.

This commit improves the previous one by also deferring the nullify of
the ax->tty pointer. Otherwise, a NULL pointer dereference bug occurs.
Partial of the stack trace is shown below.

BUG: kernel NULL pointer dereference, address: 0000000000000538
RIP: 0010:ax_xmit+0x1f9/0x400
...
Call Trace:
dev_hard_start_xmit+0xec/0x320
sch_direct_xmit+0xea/0x240
__qdisc_run+0x166/0x5c0
__dev_queue_xmit+0x2c7/0xaf0
ax25_std_establish_data_link+0x59/0x60
ax25_connect+0x3a0/0x500
? security_socket_connect+0x2b/0x40
__sys_connect+0x96/0xc0
? __hrtimer_init+0xc0/0xc0
? common_nsleep+0x2e/0x50
? switch_fpu_return+0x139/0x1a0
__x64_sys_connect+0x11/0x20
do_syscall_64+0x33/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xa9

The crash point is shown as below

static void ax_encaps(...) {
...
set_bit(TTY_DO_WRITE_WAKEUP, &ax->tty->flags); // ax->tty = NULL!
...
}

By placing the nullify action after the unregister_netdev, the ax->tty
pointer won't be assigned as NULL net_device framework layer is well
synchronized.

Signed-off-by: Lin Ma <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/hamradio/mkiss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/hamradio/mkiss.c
+++ b/drivers/net/hamradio/mkiss.c
@@ -803,14 +803,14 @@ static void mkiss_close(struct tty_struc
*/
netif_stop_queue(ax->dev);

- ax->tty = NULL;
-
unregister_netdev(ax->dev);

/* Free all AX25 frame buffers after unreg. */
kfree(ax->rbuff);
kfree(ax->xbuff);

+ ax->tty = NULL;
+
free_netdev(ax->dev);
}




2021-12-27 15:34:29

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 38/38] phonet/pep: refuse to enable an unbound pipe

From: Rémi Denis-Courmont <[email protected]>

commit 75a2f31520095600f650597c0ac41f48b5ba0068 upstream.

This ioctl() implicitly assumed that the socket was already bound to
a valid local socket name, i.e. Phonet object. If the socket was not
bound, two separate problems would occur:

1) We'd send an pipe enablement request with an invalid source object.
2) Later socket calls could BUG on the socket unexpectedly being
connected yet not bound to a valid object.

Reported-by: [email protected]
Signed-off-by: Rémi Denis-Courmont <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/phonet/pep.c | 2 ++
1 file changed, 2 insertions(+)

--- a/net/phonet/pep.c
+++ b/net/phonet/pep.c
@@ -959,6 +959,8 @@ static int pep_ioctl(struct sock *sk, in
ret = -EBUSY;
else if (sk->sk_state == TCP_ESTABLISHED)
ret = -EISCONN;
+ else if (!pn->pn_sk.sobject)
+ ret = -EADDRNOTAVAIL;
else
ret = pep_sock_enable(sk, NULL, 0);
release_sock(sk);



2021-12-27 15:35:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 17/38] fjes: Check for error irq

From: Jiasheng Jiang <[email protected]>

[ Upstream commit db6d6afe382de5a65d6ccf51253ab48b8e8336c3 ]

I find that platform_get_irq() will not always succeed.
It will return error irq in case of the failure.
Therefore, it might be better to check it if order to avoid the use of
error irq.

Fixes: 658d439b2292 ("fjes: Introduce FUJITSU Extended Socket Network Device driver")
Signed-off-by: Jiasheng Jiang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/fjes/fjes_main.c | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
index 778d3729f460a..89b3bc389f469 100644
--- a/drivers/net/fjes/fjes_main.c
+++ b/drivers/net/fjes/fjes_main.c
@@ -1284,6 +1284,11 @@ static int fjes_probe(struct platform_device *plat_dev)
hw->hw_res.start = res->start;
hw->hw_res.size = resource_size(res);
hw->hw_res.irq = platform_get_irq(plat_dev, 0);
+ if (hw->hw_res.irq < 0) {
+ err = hw->hw_res.irq;
+ goto err_free_control_wq;
+ }
+
err = fjes_hw_init(&adapter->hw);
if (err)
goto err_free_control_wq;
--
2.34.1




2021-12-27 15:35:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 19/38] sfc: falcon: Check null pointer of rx_queue->page_ring

From: Jiasheng Jiang <[email protected]>

[ Upstream commit 9b8bdd1eb5890aeeab7391dddcf8bd51f7b07216 ]

Because of the possible failure of the kcalloc, it should be better to
set rx_queue->page_ptr_mask to 0 when it happens in order to maintain
the consistency.

Fixes: 5a6681e22c14 ("sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver")
Signed-off-by: Jiasheng Jiang <[email protected]>
Acked-by: Martin Habets <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/sfc/falcon/rx.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/sfc/falcon/rx.c b/drivers/net/ethernet/sfc/falcon/rx.c
index 02456ed13a7d4..5b93a3af4575d 100644
--- a/drivers/net/ethernet/sfc/falcon/rx.c
+++ b/drivers/net/ethernet/sfc/falcon/rx.c
@@ -732,7 +732,10 @@ static void ef4_init_rx_recycle_ring(struct ef4_nic *efx,
efx->rx_bufs_per_page);
rx_queue->page_ring = kcalloc(page_ring_size,
sizeof(*rx_queue->page_ring), GFP_KERNEL);
- rx_queue->page_ptr_mask = page_ring_size - 1;
+ if (!rx_queue->page_ring)
+ rx_queue->page_ptr_mask = 0;
+ else
+ rx_queue->page_ptr_mask = page_ring_size - 1;
}

void ef4_init_rx_queue(struct ef4_rx_queue *rx_queue)
--
2.34.1




2021-12-27 15:35:13

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 20/38] hwmon: (lm90) Fix usage of CONFIG2 register in detect function

From: Guenter Roeck <[email protected]>

[ Upstream commit fce15c45d3fbd9fc1feaaf3210d8e3f8b33dfd3a ]

The detect function had a comment "Make compiler happy" when id did not
read the second configuration register. As it turns out, the code was
checking the contents of this register for manufacturer ID 0xA1 (NXP
Semiconductor/Philips), but never actually read the register. So it
wasn't surprising that the compiler complained, and it indeed had a point.
Fix the code to read the register contents for manufacturer ID 0xa1.

At the same time, the code was reading the register for manufacturer ID
0x41 (Analog Devices), but it was not using the results. In effect it was
just checking if reading the register returned an error. That doesn't
really add much if any value, so stop doing that.

Fixes: f90be42fb383 ("hwmon: (lm90) Refactor reading of config2 register")
Signed-off-by: Guenter Roeck <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/hwmon/lm90.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
index c187e557678ef..3df4e8654448b 100644
--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -1439,12 +1439,11 @@ static int lm90_detect(struct i2c_client *client,
if (man_id < 0 || chip_id < 0 || config1 < 0 || convrate < 0)
return -ENODEV;

- if (man_id == 0x01 || man_id == 0x5C || man_id == 0x41) {
+ if (man_id == 0x01 || man_id == 0x5C || man_id == 0xA1) {
config2 = i2c_smbus_read_byte_data(client, LM90_REG_R_CONFIG2);
if (config2 < 0)
return -ENODEV;
- } else
- config2 = 0; /* Make compiler happy */
+ }

if ((address == 0x4C || address == 0x4D)
&& man_id == 0x01) { /* National Semiconductor */
--
2.34.1




2021-12-27 15:35:14

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 22/38] ALSA: drivers: opl3: Fix incorrect use of vp->state

From: Colin Ian King <[email protected]>

commit 2dee54b289fbc810669a1b2b8a0887fa1c9a14d7 upstream.

Static analysis with scan-build has found an assignment to vp2 that is
never used. It seems that the check on vp->state > 0 should be actually
on vp2->state instead. Fix this.

This dates back to 2002, I found the offending commit from the git
history git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git,
commit 91e39521bbf6 ("[PATCH] ALSA patch for 2.5.4")

Signed-off-by: Colin Ian King <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/drivers/opl3/opl3_midi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/sound/drivers/opl3/opl3_midi.c
+++ b/sound/drivers/opl3/opl3_midi.c
@@ -412,7 +412,7 @@ void snd_opl3_note_on(void *p, int note,
}
if (instr_4op) {
vp2 = &opl3->voices[voice + 3];
- if (vp->state > 0) {
+ if (vp2->state > 0) {
opl3_reg = reg_side | (OPL3_REG_KEYON_BLOCK +
voice_offset + 3);
reg_val = vp->keyon_reg & ~OPL3_KEYON_BIT;



2021-12-27 15:36:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 23/38] Input: atmel_mxt_ts - fix double free in mxt_read_info_block

From: José Expósito <[email protected]>

commit 12f247ab590a08856441efdbd351cf2cc8f60a2d upstream.

The "id_buf" buffer is stored in "data->raw_info_block" and freed by
"mxt_free_object_table" in case of error.

Return instead of jumping to avoid a double free.

Addresses-Coverity-ID: 1474582 ("Double free")
Fixes: 068bdb67ef74 ("Input: atmel_mxt_ts - fix the firmware update")
Signed-off-by: José Expósito <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -1809,7 +1809,7 @@ static int mxt_read_info_block(struct mx
if (error) {
dev_err(&client->dev, "Error %d parsing object table\n", error);
mxt_free_object_table(data);
- goto err_free_mem;
+ return error;
}

data->object_table = (struct mxt_object *)(id_buf + MXT_OBJECT_START);



2021-12-27 15:36:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 21/38] ALSA: jack: Check the return value of kstrdup()

From: Xiaoke Wang <[email protected]>

commit c01c1db1dc632edafb0dff32d40daf4f9c1a4e19 upstream.

kstrdup() can return NULL, it is better to check the return value of it.

Signed-off-by: Xiaoke Wang <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/core/jack.c | 4 ++++
1 file changed, 4 insertions(+)

--- a/sound/core/jack.c
+++ b/sound/core/jack.c
@@ -234,6 +234,10 @@ int snd_jack_new(struct snd_card *card,
return -ENOMEM;

jack->id = kstrdup(id, GFP_KERNEL);
+ if (jack->id == NULL) {
+ kfree(jack);
+ return -ENOMEM;
+ }

/* don't creat input device for phantom jack */
if (!phantom_jack) {



2021-12-27 15:36:53

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 14/38] net: skip virtio_net_hdr_set_proto if protocol already set

From: Willem de Bruijn <[email protected]>

[ Upstream commit 1ed1d592113959f00cc552c3b9f47ca2d157768f ]

virtio_net_hdr_set_proto infers skb->protocol from the virtio_net_hdr
gso_type, to avoid packets getting dropped for lack of a proto type.

Its protocol choice is a guess, especially in the case of UFO, where
the single VIRTIO_NET_HDR_GSO_UDP label covers both UFOv4 and UFOv6.

Skip this best effort if the field is already initialized. Whether
explicitly from userspace, or implicitly based on an earlier call to
dev_parse_header_protocol (which is more robust, but was introduced
after this patch).

Fixes: 9d2f67e43b73 ("net/packet: fix packet drop as of virtio gso")
Signed-off-by: Willem de Bruijn <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
include/linux/virtio_net.h | 3 +++
1 file changed, 3 insertions(+)

diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 8874b278cd34a..faee73c084d49 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -25,6 +25,9 @@ static inline bool virtio_net_hdr_match_proto(__be16 protocol, __u8 gso_type)
static inline int virtio_net_hdr_set_proto(struct sk_buff *skb,
const struct virtio_net_hdr *hdr)
{
+ if (skb->protocol)
+ return 0;
+
switch (hdr->gso_type & ~VIRTIO_NET_HDR_GSO_ECN) {
case VIRTIO_NET_HDR_GSO_TCPV4:
case VIRTIO_NET_HDR_GSO_UDP:
--
2.34.1




2021-12-27 15:36:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 4.19 18/38] drivers: net: smc911x: Check for error irq

From: Jiasheng Jiang <[email protected]>

[ Upstream commit cb93b3e11d405f20a405a07482d01147ef4934a3 ]

Because platform_get_irq() could fail and return error irq.
Therefore, it might be better to check it if order to avoid the use of
error irq.

Fixes: ae150435b59e ("smsc: Move the SMC (SMSC) drivers")
Signed-off-by: Jiasheng Jiang <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
drivers/net/ethernet/smsc/smc911x.c | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/drivers/net/ethernet/smsc/smc911x.c b/drivers/net/ethernet/smsc/smc911x.c
index f97b35430c840..ac1ad00e2fc55 100644
--- a/drivers/net/ethernet/smsc/smc911x.c
+++ b/drivers/net/ethernet/smsc/smc911x.c
@@ -2080,6 +2080,11 @@ static int smc911x_drv_probe(struct platform_device *pdev)

ndev->dma = (unsigned char)-1;
ndev->irq = platform_get_irq(pdev, 0);
+ if (ndev->irq < 0) {
+ ret = ndev->irq;
+ goto release_both;
+ }
+
lp = netdev_priv(ndev);
lp->netdev = ndev;
#ifdef SMC_DYNAMIC_BUS_CONFIG
--
2.34.1




2021-12-27 21:16:59

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/38] 4.19.223-rc1 review

Hi!

> This is the start of the stable review cycle for the 4.19.223 release.
> There are 38 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.

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.19.y

Tested-by: Pavel Machek (CIP) <[email protected]>

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (643.00 B)
signature.asc (195.00 B)
Download all attachments

2021-12-28 00:55:36

by Zou Wei

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/38] 4.19.223-rc1 review



On 2021/12/27 23:30, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.223 release.
> There are 38 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 Wed, 29 Dec 2021 15:13:09 +0000.
> 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.19.223-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.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Tested on arm64 and x86 for 4.19.223-rc1,

Kernel repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-4.19.y
Version: 4.19.223-rc1
Commit: 788fd8cb07c5bb4ad111f5c437f0ebc12eac9ba1
Compiler: gcc version 7.3.0 (GCC)

arm64:
--------------------------------------------------------------------
Testcase Result Summary:
total: 8942
passed: 8942
failed: 0
timeout: 0
--------------------------------------------------------------------

x86:
--------------------------------------------------------------------
Testcase Result Summary:
total: 8942
passed: 8942
failed: 0
timeout: 0
--------------------------------------------------------------------

Tested-by: Hulk Robot <[email protected]>

2021-12-28 11:19:41

by Naresh Kamboju

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/38] 4.19.223-rc1 review

On Mon, 27 Dec 2021 at 21:03, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 4.19.223 release.
> There are 38 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 Wed, 29 Dec 2021 15:13:09 +0000.
> 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.19.223-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.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h


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

Tested-by: Linux Kernel Functional Testing <[email protected]>

## Build
* kernel: 4.19.223-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git branch: linux-4.19.y
* git commit: c3b6f5a58bb324123904facb3806b3bcc00bdccb
* git describe: v4.19.222-39-gc3b6f5a58bb3
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.222-39-gc3b6f5a58bb3

## No Test Regressions (compared to v4.19.222)

## No Test Fixes (compared to v4.19.222)

## Test result summary
total: 84075, pass: 68731, fail: 620, skip: 12910, xfail: 1814

## Build Summary
* arm: 254 total, 246 passed, 8 failed
* arm64: 35 total, 35 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 19 total, 19 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 26 total, 26 passed, 0 failed
* powerpc: 52 total, 48 passed, 4 failed
* s390: 12 total, 12 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 34 total, 34 passed, 0 failed

## Test suites summary
* fwts
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance

--
Linaro LKFT
https://lkft.linaro.org

2021-12-28 13:19:05

by Sudip Mukherjee

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/38] 4.19.223-rc1 review

Hi Greg,

On Mon, Dec 27, 2021 at 04:30:37PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.223 release.
> There are 38 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 Wed, 29 Dec 2021 15:13:09 +0000.
> Anything received after that time might be too late.

Build test:
mips (gcc version 11.2.1 20211214): 63 configs -> no failure
arm (gcc version 11.2.1 20211214): 116 configs -> no new failure
arm64 (gcc version 11.2.1 20211214): 2 configs -> no failure
x86_64 (gcc version 11.2.1 20211214): 4 configs -> no failure

Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]

[1]. https://openqa.qa.codethink.co.uk/tests/554


Tested-by: Sudip Mukherjee <[email protected]>

--
Regards
Sudip

2021-12-28 17:06:24

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/38] 4.19.223-rc1 review

On Mon, Dec 27, 2021 at 04:30:37PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.223 release.
> There are 38 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 Wed, 29 Dec 2021 15:13:09 +0000.
> Anything received after that time might be too late.
>

Build results:
total: 155 pass: 155 fail: 0
Qemu test results:
total: 422 pass: 422 fail: 0

Tested-by: Guenter Roeck <[email protected]>

Guenter

2021-12-28 21:29:51

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 4.19 00/38] 4.19.223-rc1 review

On 12/27/21 8:30 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.223 release.
> There are 38 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 Wed, 29 Dec 2021 15:13:09 +0000.
> 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.19.223-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.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Compiled and booted on my test system. No dmesg regressions.

Tested-by: Shuah Khan <[email protected]>

thanks,
-- Shuah

2021-12-29 11:21:29

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 19/38] sfc: falcon: Check null pointer of rx_queue->page_ring

Hi!

> From: Jiasheng Jiang <[email protected]>
>
> [ Upstream commit 9b8bdd1eb5890aeeab7391dddcf8bd51f7b07216 ]
>
> Because of the possible failure of the kcalloc, it should be better to
> set rx_queue->page_ptr_mask to 0 when it happens in order to maintain
> the consistency.

Again this is confusing/wrong, or at least not a complete fix...

> +++ b/drivers/net/ethernet/sfc/falcon/rx.c
> @@ -732,7 +732,10 @@ static void ef4_init_rx_recycle_ring(struct ef4_nic *efx,
> efx->rx_bufs_per_page);
> rx_queue->page_ring = kcalloc(page_ring_size,
> sizeof(*rx_queue->page_ring), GFP_KERNEL);
> - rx_queue->page_ptr_mask = page_ring_size - 1;
> + if (!rx_queue->page_ring)
> + rx_queue->page_ptr_mask = 0;
> + else
> + rx_queue->page_ptr_mask = page_ring_size - 1;
> }
>

...as we have

index = rx_queue->page_remove & rx_queue->page_ptr_mask;
page = rx_queue->page_ring[index];

in ef4_reuse_page, and similar problems in other places, including

for (i = 0; i <= rx_queue->page_ptr_mask; i++) {
struct page *page = rx_queue->page_ring[i];

. Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (1.25 kB)
signature.asc (181.00 B)
Digital signature
Download all attachments

2021-12-30 10:52:44

by Pavel Machek

[permalink] [raw]
Subject: Re: [PATCH 4.19 30/38] f2fs: fix to do sanity check on last xattr entry in __f2fs_setxattr()

Hi!

> From: Chao Yu <[email protected]>
>
> commit 5598b24efaf4892741c798b425d543e4bed357a1 upstream.

Not sure what went wrong here, but as far as I can tell, this patch is
_not_ yet in upstream.

git log:

commit eec4df26e24e978e49ccf9bcf49ca0f2ccdaeffe
Merge: e7c124bd0463 4eb1782eaa9f
Author: Linus Torvalds <[email protected]>
Date: Wed Dec 29 10:07:20 2021 -0800

pavel@amd:/data/l/clean-cg$ git show
5598b24efaf4892741c798b425d543e4bed357a1
fatal: bad object 5598b24efaf4892741c798b425d543e4bed357a1

Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (694.00 B)
signature.asc (181.00 B)
Digital signature
Download all attachments