This is the start of the stable review cycle for the 4.14.252 release. There are 39 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, 20 Oct 2021 13:23:15 +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.14.252-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.14.252-rc1
Vegard Nossum vegard.nossum@oracle.com r8152: select CRC32 and CRYPTO/CRYPTO_HASH/CRYPTO_SHA256
chongjiapeng jiapeng.chong@linux.alibaba.com qed: Fix missing error code in qed_slowpath_start()
Jackie Liu liuyun01@kylinos.cn acpi/arm64: fix next_platform_timer() section mismatch error
Dan Carpenter dan.carpenter@oracle.com drm/msm/dsi: fix off by one in dsi_bus_clk_enable error handling
Colin Ian King colin.king@canonical.com drm/msm: Fix null pointer dereference on pointer edp
Dan Carpenter dan.carpenter@oracle.com pata_legacy: fix a couple uninitialized variable bugs
Ziyang Xuan william.xuanziyang@huawei.com NFC: digital: fix possible memory leak in digital_in_send_sdd_req()
Ziyang Xuan william.xuanziyang@huawei.com NFC: digital: fix possible memory leak in digital_tg_listen_mdaa()
Ziyang Xuan william.xuanziyang@huawei.com nfc: fix error handling of nfc_proto_register()
Arnd Bergmann arnd@arndb.de ethernet: s2io: fix setting mac address during resume
Nanyong Sun sunnanyong@huawei.com net: encx24j600: check error in devm_regmap_init_encx24j600
Vegard Nossum vegard.nossum@oracle.com net: korina: select CRC32
Vegard Nossum vegard.nossum@oracle.com net: arc: select CRC32
Eiichi Tsukata eiichi.tsukata@nutanix.com sctp: account stream padding length for reconf chunk
Dan Carpenter dan.carpenter@oracle.com iio: ssp_sensors: fix error code in ssp_print_mcu_debug()
Dan Carpenter dan.carpenter@oracle.com iio: ssp_sensors: add more range checking in ssp_parse_dataframe()
Jiri Valek - 2N valek@2n.cz iio: light: opt3001: Fixed timeout error when 0 lux
Christophe JAILLET christophe.jaillet@wanadoo.fr iio: adc128s052: Fix the error handling path of 'adc128_probe()'
Billy Tsai billy_tsai@aspeedtech.com iio: adc: aspeed: set driver data when adc probe.
Borislav Petkov bp@suse.de x86/Kconfig: Do not enable AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT automatically
Stephen Boyd swboyd@chromium.org nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells
Halil Pasic pasic@linux.ibm.com virtio: write back F_VERSION_1 before validate
Tomaz Solc tomaz.solc@tablix.org USB: serial: option: add prod. id for Quectel EG91
Daniele Palmas dnlplm@gmail.com USB: serial: option: add Telit LE910Cx composition 0x1204
Yu-Tung Chang mtwget@gmail.com USB: serial: option: add Quectel EC200S-CN module support
Aleksander Morgado aleksander@aleksander.es USB: serial: qcserial: add EM9191 QDL support
Michael Cullen michael@michaelcullen.name Input: xpad - add support for another USB ID of Nacon GC-100
Miquel Raynal miquel.raynal@bootlin.com usb: musb: dsps: Fix the probe error path
Zhang Jianhua chris.zjh@huawei.com efi: Change down_interruptible() in virt_efi_reset_system() to down_trylock()
Ard Biesheuvel ardb@kernel.org efi/cper: use stack buffer for error record decoding
Arnd Bergmann arnd@arndb.de cb710: avoid NULL pointer subtraction
Nikolay Martynov mar.kolya@gmail.com xhci: Enable trust tx length quirk for Fresco FL11 USB controller
Pavankumar Kondeti pkondeti@codeaurora.org xhci: Fix command ring pointer corruption while aborting a command
Filipe Manana fdmanana@suse.com btrfs: check for error when looking up inode during dir entry replay
Filipe Manana fdmanana@suse.com btrfs: deal with errors when adding inode reference during log replay
Filipe Manana fdmanana@suse.com btrfs: deal with errors when replaying dir entry during log replay
Roberto Sassu roberto.sassu@huawei.com s390: fix strrchr() implementation
Takashi Iwai tiwai@suse.de ALSA: seq: Fix a potential UAF by wrong private_free call order
Sasha Levin sashal@kernel.org stable: clamp SUBLEVEL in 4.14
-------------
Diffstat:
Makefile | 6 ++-- arch/s390/lib/string.c | 15 +++++----- arch/x86/Kconfig | 1 - drivers/acpi/arm64/gtdt.c | 2 +- drivers/ata/pata_legacy.c | 6 ++-- drivers/firmware/efi/cper.c | 4 +-- drivers/firmware/efi/runtime-wrappers.c | 2 +- drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +- drivers/gpu/drm/msm/edp/edp_ctrl.c | 3 +- drivers/iio/adc/aspeed_adc.c | 1 + drivers/iio/adc/ti-adc128s052.c | 6 ++++ drivers/iio/common/ssp_sensors/ssp_spi.c | 11 ++++++-- drivers/iio/light/opt3001.c | 6 ++-- drivers/input/joystick/xpad.c | 2 ++ drivers/misc/cb710/sgbuf2.c | 2 +- drivers/net/ethernet/Kconfig | 1 + drivers/net/ethernet/arc/Kconfig | 1 + drivers/net/ethernet/microchip/encx24j600-regmap.c | 10 +++++-- drivers/net/ethernet/microchip/encx24j600.c | 5 +++- drivers/net/ethernet/microchip/encx24j600_hw.h | 4 +-- drivers/net/ethernet/neterion/s2io.c | 2 +- drivers/net/ethernet/qlogic/qed/qed_main.c | 1 + drivers/net/usb/Kconfig | 4 +++ drivers/nvmem/core.c | 3 +- drivers/usb/host/xhci-pci.c | 2 ++ drivers/usb/host/xhci-ring.c | 14 +++++++--- drivers/usb/musb/musb_dsps.c | 4 ++- drivers/usb/serial/option.c | 8 ++++++ drivers/usb/serial/qcserial.c | 1 + drivers/virtio/virtio.c | 11 ++++++++ fs/btrfs/tree-log.c | 32 +++++++++++++++------- net/nfc/af_nfc.c | 3 ++ net/nfc/digital_core.c | 9 ++++-- net/nfc/digital_technology.c | 8 ++++-- net/sctp/sm_make_chunk.c | 2 +- sound/core/seq_device.c | 8 ++---- 36 files changed, 144 insertions(+), 58 deletions(-)
From: Sasha Levin sashal@kernel.org
Right now SUBLEVEL is overflowing, and some userspace may start treating 4.14.256 as 4.15. While out of tree modules have different ways of extracting the version number (and we're generally ok with breaking them), we do care about breaking userspace and it would appear that this overflow might do just that.
Our rules around userspace ABI in the stable kernel are pretty simple: we don't break it. Thus, while userspace may be checking major/minor, it shouldn't be doing anything with sublevel.
This patch applies a big band-aid to the 4.14 kernel in the form of clamping the sublevel to 255.
The clamp is done for the purpose of LINUX_VERSION_CODE only, and extracting the version number from the Makefile or "make kernelversion" will continue to work as intended.
We might need to do it later in newer trees, but maybe we'll have a better solution by then, so I'm ignoring that problem for now.
Signed-off-by: Sasha Levin sashal@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/Makefile +++ b/Makefile @@ -1162,7 +1162,7 @@ endef
define filechk_version.h (echo #define LINUX_VERSION_CODE $(shell \ - expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 0$(SUBLEVEL)); \ + expr $(VERSION) * 65536 + 0$(PATCHLEVEL) * 256 + 255); \ echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';) endef
From: Takashi Iwai tiwai@suse.de
commit 1f8763c59c4ec6254d629fe77c0a52220bd907aa upstream.
John Keeping reported and posted a patch for a potential UAF in rawmidi sequencer destruction: the snd_rawmidi_dev_seq_free() may be called after the associated rawmidi object got already freed. After a deeper look, it turned out that the bug is rather the incorrect private_free call order for a snd_seq_device. The snd_seq_device private_free gets called at the release callback of the sequencer device object, while this was rather expected to be executed at the snd_device call chains that runs at the beginning of the whole card-free procedure. It's been broken since the rewrite of sequencer-device binding (although it hasn't surfaced because the sequencer device release happens usually right along with the card device release).
This patch corrects the private_free call to be done in the right place, at snd_seq_device_dev_free().
Fixes: 7c37ae5c625a ("ALSA: seq: Rewrite sequencer device binding with standard bus") Reported-and-tested-by: John Keeping john@metanate.com Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210930114114.8645-1-tiwai@suse.de Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- sound/core/seq_device.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
--- a/sound/core/seq_device.c +++ b/sound/core/seq_device.c @@ -162,6 +162,8 @@ static int snd_seq_device_dev_free(struc struct snd_seq_device *dev = device->device_data;
cancel_autoload_drivers(); + if (dev->private_free) + dev->private_free(dev); put_device(&dev->dev); return 0; } @@ -189,11 +191,7 @@ static int snd_seq_device_dev_disconnect
static void snd_seq_dev_release(struct device *dev) { - struct snd_seq_device *sdev = to_seq_dev(dev); - - if (sdev->private_free) - sdev->private_free(sdev); - kfree(sdev); + kfree(to_seq_dev(dev)); }
/*
From: Roberto Sassu roberto.sassu@huawei.com
commit 8e0ab8e26b72a80e991c66a8abc16e6c856abe3d upstream.
Fix two problems found in the strrchr() implementation for s390 architectures: evaluate empty strings (return the string address instead of NULL, if '\0' is passed as second argument); evaluate the first character of non-empty strings (the current implementation stops at the second).
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Reported-by: Heiko Carstens hca@linux.ibm.com (incorrect behavior with empty strings) Signed-off-by: Roberto Sassu roberto.sassu@huawei.com Link: https://lore.kernel.org/r/20211005120836.60630-1-roberto.sassu@huawei.com Signed-off-by: Heiko Carstens hca@linux.ibm.com Signed-off-by: Vasily Gorbik gor@linux.ibm.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- arch/s390/lib/string.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-)
--- a/arch/s390/lib/string.c +++ b/arch/s390/lib/string.c @@ -227,14 +227,13 @@ EXPORT_SYMBOL(strcmp); */ char * strrchr(const char * s, int c) { - size_t len = __strend(s) - s; + ssize_t len = __strend(s) - s;
- if (len) - do { - if (s[len] == (char) c) - return (char *) s + len; - } while (--len > 0); - return NULL; + do { + if (s[len] == (char)c) + return (char *)s + len; + } while (--len >= 0); + return NULL; } EXPORT_SYMBOL(strrchr);
From: Filipe Manana fdmanana@suse.com
commit e15ac6413745e3def00e663de00aea5a717311c1 upstream.
At replay_one_one(), we are treating any error returned from btrfs_lookup_dir_item() or from btrfs_lookup_dir_index_item() as meaning that there is no existing directory entry in the fs/subvolume tree. This is not correct since we can get errors such as, for example, -EIO when reading extent buffers while searching the fs/subvolume's btree.
So fix that and return the error to the caller when it is not -ENOENT.
CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana fdmanana@suse.com Reviewed-by: David Sterba dsterba@suse.com Signed-off-by: David Sterba dsterba@suse.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- fs/btrfs/tree-log.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
--- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -1766,7 +1766,14 @@ static noinline int replay_one_name(stru ret = -EINVAL; goto out; } - if (IS_ERR_OR_NULL(dst_di)) { + + if (dst_di == ERR_PTR(-ENOENT)) + dst_di = NULL; + + if (IS_ERR(dst_di)) { + ret = PTR_ERR(dst_di); + goto out; + } else if (!dst_di) { /* we need a sequence number to insert, so we only * do inserts for the BTRFS_DIR_INDEX_KEY types */
From: Filipe Manana fdmanana@suse.com
commit 52db77791fe24538c8aa2a183248399715f6b380 upstream.
At __inode_add_ref(), we treating any error returned from btrfs_lookup_dir_item() or from btrfs_lookup_dir_index_item() as meaning that there is no existing directory entry in the fs/subvolume tree. This is not correct since we can get errors such as, for example, -EIO when reading extent buffers while searching the fs/subvolume's btree.
So fix that and return the error to the caller when it is not -ENOENT.
CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana fdmanana@suse.com Reviewed-by: David Sterba dsterba@suse.com Signed-off-by: David Sterba dsterba@suse.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- fs/btrfs/tree-log.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
--- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -1161,7 +1161,10 @@ next: /* look for a conflicting sequence number */ di = btrfs_lookup_dir_index_item(trans, root, path, btrfs_ino(dir), ref_index, name, namelen, 0); - if (di && !IS_ERR(di)) { + if (IS_ERR(di)) { + if (PTR_ERR(di) != -ENOENT) + return PTR_ERR(di); + } else if (di) { ret = drop_one_dir_item(trans, root, path, dir, di); if (ret) return ret; @@ -1171,7 +1174,9 @@ next: /* look for a conflicing name */ di = btrfs_lookup_dir_item(trans, root, path, btrfs_ino(dir), name, namelen, 0); - if (di && !IS_ERR(di)) { + if (IS_ERR(di)) { + return PTR_ERR(di); + } else if (di) { ret = drop_one_dir_item(trans, root, path, dir, di); if (ret) return ret;
From: Filipe Manana fdmanana@suse.com
commit cfd312695b71df04c3a2597859ff12c470d1e2e4 upstream.
At replay_one_name(), we are treating any error from btrfs_lookup_inode() as if the inode does not exists. Fix this by checking for an error and returning it to the caller.
CC: stable@vger.kernel.org # 4.14+ Signed-off-by: Filipe Manana fdmanana@suse.com Reviewed-by: David Sterba dsterba@suse.com Signed-off-by: David Sterba dsterba@suse.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- fs/btrfs/tree-log.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
--- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -1730,8 +1730,8 @@ static noinline int replay_one_name(stru struct btrfs_key log_key; struct inode *dir; u8 log_type; - int exists; - int ret = 0; + bool exists; + int ret; bool update_size = (key->type == BTRFS_DIR_INDEX_KEY); bool name_added = false;
@@ -1751,12 +1751,12 @@ static noinline int replay_one_name(stru name_len);
btrfs_dir_item_key_to_cpu(eb, di, &log_key); - exists = btrfs_lookup_inode(trans, root, path, &log_key, 0); - if (exists == 0) - exists = 1; - else - exists = 0; + ret = btrfs_lookup_inode(trans, root, path, &log_key, 0); btrfs_release_path(path); + if (ret < 0) + goto out; + exists = (ret == 0); + ret = 0;
if (key->type == BTRFS_DIR_ITEM_KEY) { dst_di = btrfs_lookup_dir_item(trans, root, path, key->objectid,
From: Pavankumar Kondeti pkondeti@codeaurora.org
commit ff0e50d3564f33b7f4b35cadeabd951d66cfc570 upstream.
The command ring pointer is located at [6:63] bits of the command ring control register (CRCR). All the control bits like command stop, abort are located at [0:3] bits. While aborting a command, we read the CRCR and set the abort bit and write to the CRCR. The read will always give command ring pointer as all zeros. So we essentially write only the control bits. Since we split the 64 bit write into two 32 bit writes, there is a possibility of xHC command ring stopped before the upper dword (all zeros) is written. If that happens, xHC updates the upper dword of its internal command ring pointer with all zeros. Next time, when the command ring is restarted, we see xHC memory access failures. Fix this issue by only writing to the lower dword of CRCR where all control bits are located.
Cc: stable@vger.kernel.org Signed-off-by: Pavankumar Kondeti pkondeti@codeaurora.org Signed-off-by: Mathias Nyman mathias.nyman@linux.intel.com Link: https://lore.kernel.org/r/20211008092547.3996295-5-mathias.nyman@linux.intel... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/usb/host/xhci-ring.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
--- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -350,16 +350,22 @@ static void xhci_handle_stopped_cmd_ring /* Must be called with xhci->lock held, releases and aquires lock back */ static int xhci_abort_cmd_ring(struct xhci_hcd *xhci, unsigned long flags) { - u64 temp_64; + u32 temp_32; int ret;
xhci_dbg(xhci, "Abort command ring\n");
reinit_completion(&xhci->cmd_ring_stop_completion);
- temp_64 = xhci_read_64(xhci, &xhci->op_regs->cmd_ring); - xhci_write_64(xhci, temp_64 | CMD_RING_ABORT, - &xhci->op_regs->cmd_ring); + /* + * The control bits like command stop, abort are located in lower + * dword of the command ring control register. Limit the write + * to the lower dword to avoid corrupting the command ring pointer + * in case if the command ring is stopped by the time upper dword + * is written. + */ + temp_32 = readl(&xhci->op_regs->cmd_ring); + writel(temp_32 | CMD_RING_ABORT, &xhci->op_regs->cmd_ring);
/* Section 4.6.1.2 of xHCI 1.0 spec says software should also time the * completion of the Command Abort operation. If CRR is not negated in 5
From: Nikolay Martynov mar.kolya@gmail.com
commit ea0f69d8211963c4b2cc1998b86779a500adb502 upstream.
Tested on SD5200T TB3 dock which has Fresco Logic FL1100 USB 3.0 Host Controller. Before this patch streaming video from USB cam made mouse and keyboard connected to the same USB bus unusable. Also video was jerky. With this patch streaming video doesn't have any effect on other periferals and video is smooth.
Cc: stable@vger.kernel.org Signed-off-by: Nikolay Martynov mar.kolya@gmail.com Signed-off-by: Mathias Nyman mathias.nyman@linux.intel.com Link: https://lore.kernel.org/r/20211008092547.3996295-6-mathias.nyman@linux.intel... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/usb/host/xhci-pci.c | 2 ++ 1 file changed, 2 insertions(+)
--- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -38,6 +38,7 @@ #define PCI_VENDOR_ID_FRESCO_LOGIC 0x1b73 #define PCI_DEVICE_ID_FRESCO_LOGIC_PDK 0x1000 #define PCI_DEVICE_ID_FRESCO_LOGIC_FL1009 0x1009 +#define PCI_DEVICE_ID_FRESCO_LOGIC_FL1100 0x1100 #define PCI_DEVICE_ID_FRESCO_LOGIC_FL1400 0x1400
#define PCI_VENDOR_ID_ETRON 0x1b6f @@ -99,6 +100,7 @@ static void xhci_pci_quirks(struct devic /* Look for vendor-specific quirks */ if (pdev->vendor == PCI_VENDOR_ID_FRESCO_LOGIC && (pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_PDK || + pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_FL1100 || pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_FL1400)) { if (pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_PDK && pdev->revision == 0x0) {
From: Arnd Bergmann arnd@arndb.de
commit 42641042c10c757fe10cc09088cf3f436cec5007 upstream.
clang-14 complains about an unusual way of converting a pointer to an integer:
drivers/misc/cb710/sgbuf2.c:50:15: error: performing pointer subtraction with a null pointer has undefined behavior [-Werror,-Wnull-pointer-subtraction] return ((ptr - NULL) & 3) != 0;
Replace this with a normal cast to uintptr_t.
Fixes: 5f5bac8272be ("mmc: Driver for CB710/720 memory card reader (MMC part)") Cc: stable stable@vger.kernel.org Signed-off-by: Arnd Bergmann arnd@arndb.de Link: https://lore.kernel.org/r/20210927121408.939246-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/misc/cb710/sgbuf2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/misc/cb710/sgbuf2.c +++ b/drivers/misc/cb710/sgbuf2.c @@ -50,7 +50,7 @@ static inline bool needs_unaligned_copy( #ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS return false; #else - return ((ptr - NULL) & 3) != 0; + return ((uintptr_t)ptr & 3) != 0; #endif }
From: Ard Biesheuvel ardb@kernel.org
commit b3a72ca80351917cc23f9e24c35f3c3979d3c121 upstream.
Joe reports that using a statically allocated buffer for converting CPER error records into human readable text is probably a bad idea. Even though we are not aware of any actual issues, a stack buffer is clearly a better choice here anyway, so let's move the buffer into the stack frames of the two functions that refer to it.
Cc: stable@vger.kernel.org Reported-by: Joe Perches joe@perches.com Signed-off-by: Ard Biesheuvel ardb@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/firmware/efi/cper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/firmware/efi/cper.c +++ b/drivers/firmware/efi/cper.c @@ -39,8 +39,6 @@
#define INDENT_SP " "
-static char rcd_decode_str[CPER_REC_LEN]; - /* * CPER record ID need to be unique even after reboot, because record * ID is used as index for ERST storage, while CPER records from @@ -416,6 +414,7 @@ const char *cper_mem_err_unpack(struct t struct cper_mem_err_compact *cmem) { const char *ret = trace_seq_buffer_ptr(p); + char rcd_decode_str[CPER_REC_LEN];
if (cper_mem_err_location(cmem, rcd_decode_str)) trace_seq_printf(p, "%s", rcd_decode_str); @@ -430,6 +429,7 @@ static void cper_print_mem(const char *p int len) { struct cper_mem_err_compact cmem; + char rcd_decode_str[CPER_REC_LEN];
/* Don't trust UEFI 2.1/2.2 structure with bad validation bits */ if (len == sizeof(struct cper_sec_mem_err_old) &&
From: Zhang Jianhua chris.zjh@huawei.com
commit 38fa3206bf441911258e5001ac8b6738693f8d82 upstream.
While reboot the system by sysrq, the following bug will be occur.
BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:90 in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 10052, name: rc.shutdown CPU: 3 PID: 10052 Comm: rc.shutdown Tainted: G W O 5.10.0 #1 Call trace: dump_backtrace+0x0/0x1c8 show_stack+0x18/0x28 dump_stack+0xd0/0x110 ___might_sleep+0x14c/0x160 __might_sleep+0x74/0x88 down_interruptible+0x40/0x118 virt_efi_reset_system+0x3c/0xd0 efi_reboot+0xd4/0x11c machine_restart+0x60/0x9c emergency_restart+0x1c/0x2c sysrq_handle_reboot+0x1c/0x2c __handle_sysrq+0xd0/0x194 write_sysrq_trigger+0xbc/0xe4 proc_reg_write+0xd4/0xf0 vfs_write+0xa8/0x148 ksys_write+0x6c/0xd8 __arm64_sys_write+0x18/0x28 el0_svc_common.constprop.3+0xe4/0x16c do_el0_svc+0x1c/0x2c el0_svc+0x20/0x30 el0_sync_handler+0x80/0x17c el0_sync+0x158/0x180
The reason for this problem is that irq has been disabled in machine_restart() and then it calls down_interruptible() in virt_efi_reset_system(), which would occur sleep in irq context, it is dangerous! Commit 99409b935c9a("locking/semaphore: Add might_sleep() to down_*() family") add might_sleep() in down_interruptible(), so the bug info is here. down_trylock() can solve this problem, cause there is no might_sleep.
--------
Cc: stable@vger.kernel.org Signed-off-by: Zhang Jianhua chris.zjh@huawei.com Signed-off-by: Ard Biesheuvel ardb@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/firmware/efi/runtime-wrappers.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/firmware/efi/runtime-wrappers.c +++ b/drivers/firmware/efi/runtime-wrappers.c @@ -259,7 +259,7 @@ static void virt_efi_reset_system(int re unsigned long data_size, efi_char16_t *data) { - if (down_interruptible(&efi_runtime_lock)) { + if (down_trylock(&efi_runtime_lock)) { pr_warn("failed to invoke the reset_system() runtime service:\n" "could not get exclusive access to the firmware\n"); return;
From: Miquel Raynal miquel.raynal@bootlin.com
commit c2115b2b16421d93d4993f3fe4c520e91d6fe801 upstream.
Commit 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after initializing musb") has inverted the calls to dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev() without updating correctly the error path. dsps_create_musb_pdev() allocates and registers a new platform device which must be unregistered and freed with platform_device_unregister(), and this is missing upon dsps_setup_optional_vbus_irq() error.
While on the master branch it seems not to trigger any issue, I observed a kernel crash because of a NULL pointer dereference with a v5.10.70 stable kernel where the patch mentioned above was backported. With this kernel version, -EPROBE_DEFER is returned the first time dsps_setup_optional_vbus_irq() is called which triggers the probe to error out without unregistering the platform device. Unfortunately, on the Beagle Bone Black Wireless, the platform device still living in the system is being used by the USB Ethernet gadget driver, which during the boot phase triggers the crash.
My limited knowledge of the musb world prevents me to revert this commit which was sent to silence a robot warning which, as far as I understand, does not make sense. The goal of this patch was to prevent an IRQ to fire before the platform device being registered. I think this cannot ever happen due to the fact that enabling the interrupts is done by the ->enable() callback of the platform musb device, and this platform device must be already registered in order for the core or any other user to use this callback.
Hence, I decided to fix the error path, which might prevent future errors on mainline kernels while also fixing older ones.
Fixes: 7c75bde329d7 ("usb: musb: musb_dsps: request_irq() after initializing musb") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal miquel.raynal@bootlin.com Link: https://lore.kernel.org/r/20211005221631.1529448-1-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/usb/musb/musb_dsps.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -939,11 +939,13 @@ static int dsps_probe(struct platform_de if (usb_get_dr_mode(&pdev->dev) == USB_DR_MODE_PERIPHERAL) { ret = dsps_setup_optional_vbus_irq(pdev, glue); if (ret) - goto err; + goto unregister_pdev; }
return 0;
+unregister_pdev: + platform_device_unregister(glue->musb); err: pm_runtime_disable(&pdev->dev); iounmap(glue->usbss_base);
From: Michael Cullen michael@michaelcullen.name
commit 3378a07daa6cdd11e042797454c706d1c69f9ca6 upstream.
The Nacon GX100XF is already mapped, but it seems there is a Nacon GC-100 (identified as NC5136Wht PCGC-100WHITE though I believe other colours exist) with a different USB ID when in XInput mode.
Signed-off-by: Michael Cullen michael@michaelcullen.name Link: https://lore.kernel.org/r/20211015192051.5196-1-michael@michaelcullen.name Signed-off-by: Dmitry Torokhov dmitry.torokhov@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/input/joystick/xpad.c | 2 ++ 1 file changed, 2 insertions(+)
--- a/drivers/input/joystick/xpad.c +++ b/drivers/input/joystick/xpad.c @@ -348,6 +348,7 @@ static const struct xpad_device { { 0x24c6, 0x5b03, "Thrustmaster Ferrari 458 Racing Wheel", 0, XTYPE_XBOX360 }, { 0x24c6, 0x5d04, "Razer Sabertooth", 0, XTYPE_XBOX360 }, { 0x24c6, 0xfafe, "Rock Candy Gamepad for Xbox 360", 0, XTYPE_XBOX360 }, + { 0x3285, 0x0607, "Nacon GC-100", 0, XTYPE_XBOX360 }, { 0x3767, 0x0101, "Fanatec Speedster 3 Forceshock Wheel", 0, XTYPE_XBOX }, { 0xffff, 0xffff, "Chinese-made Xbox Controller", 0, XTYPE_XBOX }, { 0x0000, 0x0000, "Generic X-Box pad", 0, XTYPE_UNKNOWN } @@ -464,6 +465,7 @@ static const struct usb_device_id xpad_t XPAD_XBOXONE_VENDOR(0x24c6), /* PowerA Controllers */ XPAD_XBOXONE_VENDOR(0x2e24), /* Hyperkin Duke X-Box One pad */ XPAD_XBOX360_VENDOR(0x2f24), /* GameSir Controllers */ + XPAD_XBOX360_VENDOR(0x3285), /* Nacon GC-100 */ { } };
From: Aleksander Morgado aleksander@aleksander.es
commit 11c52d250b34a0862edc29db03fbec23b30db6da upstream.
When the module boots into QDL download mode it exposes the 1199:90d2 ids, which can be mapped to the qcserial driver, and used to run firmware upgrades (e.g. with the qmi-firmware-update program).
T: Bus=01 Lev=03 Prnt=08 Port=03 Cnt=01 Dev#= 10 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1199 ProdID=90d2 Rev=00.00 S: Manufacturer=Sierra Wireless, Incorporated S: Product=Sierra Wireless EM9191 S: SerialNumber=8W0382004102A109 C: #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=2mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=10 Driver=qcserial
Signed-off-by: Aleksander Morgado aleksander@aleksander.es Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold johan@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/usb/serial/qcserial.c | 1 + 1 file changed, 1 insertion(+)
--- a/drivers/usb/serial/qcserial.c +++ b/drivers/usb/serial/qcserial.c @@ -169,6 +169,7 @@ static const struct usb_device_id id_tab {DEVICE_SWI(0x1199, 0x907b)}, /* Sierra Wireless EM74xx */ {DEVICE_SWI(0x1199, 0x9090)}, /* Sierra Wireless EM7565 QDL */ {DEVICE_SWI(0x1199, 0x9091)}, /* Sierra Wireless EM7565 */ + {DEVICE_SWI(0x1199, 0x90d2)}, /* Sierra Wireless EM9191 QDL */ {DEVICE_SWI(0x413c, 0x81a2)}, /* Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card */ {DEVICE_SWI(0x413c, 0x81a3)}, /* Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card */ {DEVICE_SWI(0x413c, 0x81a4)}, /* Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card */
From: Yu-Tung Chang mtwget@gmail.com
commit 2263eb7370060bdb0013bc14e1a7c9bf33617a55 upstream.
Add usb product id of the Quectel EC200S-CN module.
usb-devices output for 0x6002: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=6002 Rev=03.18 S: Manufacturer=Android S: Product=Android S: SerialNumber=0000 C: #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I: If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
Signed-off-by: Yu-Tung Chang mtwget@gmail.com Link: https://lore.kernel.org/r/20210930021112.330396-1-mtwget@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold johan@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/usb/serial/option.c | 2 ++ 1 file changed, 2 insertions(+)
--- a/drivers/usb/serial/option.c +++ b/drivers/usb/serial/option.c @@ -254,6 +254,7 @@ static void option_instat_callback(struc #define QUECTEL_PRODUCT_EP06 0x0306 #define QUECTEL_PRODUCT_EM12 0x0512 #define QUECTEL_PRODUCT_RM500Q 0x0800 +#define QUECTEL_PRODUCT_EC200S_CN 0x6002 #define QUECTEL_PRODUCT_EC200T 0x6026
#define CMOTECH_VENDOR_ID 0x16d8 @@ -1131,6 +1132,7 @@ static const struct usb_device_id option { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RM500Q, 0xff, 0, 0) }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_RM500Q, 0xff, 0xff, 0x10), .driver_info = ZLP }, + { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC200S_CN, 0xff, 0, 0) }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC200T, 0xff, 0, 0) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
From: Daniele Palmas dnlplm@gmail.com
commit f5a8a07edafed8bede17a95ef8940fe3a57a77d5 upstream.
Add the following Telit LE910Cx composition:
0x1204: tty, adb, mbim, tty, tty, tty, tty
Signed-off-by: Daniele Palmas dnlplm@gmail.com Link: https://lore.kernel.org/r/20211004105655.8515-1-dnlplm@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold johan@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/usb/serial/option.c | 2 ++ 1 file changed, 2 insertions(+)
--- a/drivers/usb/serial/option.c +++ b/drivers/usb/serial/option.c @@ -1232,6 +1232,8 @@ static const struct usb_device_id option .driver_info = NCTRL(0) | RSVD(1) | RSVD(2) }, { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1203, 0xff), /* Telit LE910Cx (RNDIS) */ .driver_info = NCTRL(2) | RSVD(3) }, + { USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1204, 0xff), /* Telit LE910Cx (MBIM) */ + .driver_info = NCTRL(0) | RSVD(1) }, { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE910_USBCFG4), .driver_info = NCTRL(0) | RSVD(1) | RSVD(2) | RSVD(3) }, { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_LE920),
From: Tomaz Solc tomaz.solc@tablix.org
commit c184accc4a42c7872dc8e8d0fc97a740dc61fe24 upstream.
Adding support for Quectel EG91 LTE module.
The interface layout is same as for EG95.
usb-devices output: T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=0191 Rev=03.18 S: Manufacturer=Android S: Product=Android C: #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#=0x1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
Interfaces:
0: Diag 1: GNSS 2: AT-command interface/modem 3: Modem 4: QMI
Signed-off-by: Tomaz Solc tomaz.solc@tablix.org Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold johan@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/usb/serial/option.c | 4 ++++ 1 file changed, 4 insertions(+)
--- a/drivers/usb/serial/option.c +++ b/drivers/usb/serial/option.c @@ -249,6 +249,7 @@ static void option_instat_callback(struc /* These Quectel products use Quectel's vendor ID */ #define QUECTEL_PRODUCT_EC21 0x0121 #define QUECTEL_PRODUCT_EC25 0x0125 +#define QUECTEL_PRODUCT_EG91 0x0191 #define QUECTEL_PRODUCT_EG95 0x0195 #define QUECTEL_PRODUCT_BG96 0x0296 #define QUECTEL_PRODUCT_EP06 0x0306 @@ -1115,6 +1116,9 @@ static const struct usb_device_id option { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25, 0xff, 0xff, 0xff), .driver_info = NUMEP2 }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25, 0xff, 0, 0) }, + { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EG91, 0xff, 0xff, 0xff), + .driver_info = NUMEP2 }, + { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EG91, 0xff, 0, 0) }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EG95, 0xff, 0xff, 0xff), .driver_info = NUMEP2 }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EG95, 0xff, 0, 0) },
From: Halil Pasic pasic@linux.ibm.com
commit 2f9a174f918e29608564c7a4e8329893ab604fb4 upstream.
The virtio specification virtio-v1.1-cs01 states: "Transitional devices MUST detect Legacy drivers by detecting that VIRTIO_F_VERSION_1 has not been acknowledged by the driver." This is exactly what QEMU as of 6.1 has done relying solely on VIRTIO_F_VERSION_1 for detecting that.
However, the specification also says: "... the driver MAY read (but MUST NOT write) the device-specific configuration fields to check that it can support the device ..." before setting FEATURES_OK.
In that case, any transitional device relying solely on VIRTIO_F_VERSION_1 for detecting legacy drivers will return data in legacy format. In particular, this implies that it is in big endian format for big endian guests. This naturally confuses the driver which expects little endian in the modern mode.
It is probably a good idea to amend the spec to clarify that VIRTIO_F_VERSION_1 can only be relied on after the feature negotiation is complete. Before validate callback existed, config space was only read after FEATURES_OK. However, we already have two regressions, so let's address this here as well.
The regressions affect the VIRTIO_NET_F_MTU feature of virtio-net and the VIRTIO_BLK_F_BLK_SIZE feature of virtio-blk for BE guests when virtio 1.0 is used on both sides. The latter renders virtio-blk unusable with DASD backing, because things simply don't work with the default. See Fixes tags for relevant commits.
For QEMU, we can work around the issue by writing out the feature bits with VIRTIO_F_VERSION_1 bit set. We (ab)use the finalize_features config op for this. This isn't enough to address all vhost devices since these do not get the features until FEATURES_OK, however it looks like the affected devices actually never handled the endianness for legacy mode correctly, so at least that's not a regression.
No devices except virtio net and virtio blk seem to be affected.
Long term the right thing to do is to fix the hypervisors.
Cc: stable@vger.kernel.org #v4.11 Signed-off-by: Halil Pasic pasic@linux.ibm.com Fixes: 82e89ea077b9 ("virtio-blk: Add validation for block size in config space") Fixes: fe36cbe0671e ("virtio_net: clear MTU when out of range") Reported-by: markver@us.ibm.com Reviewed-by: Cornelia Huck cohuck@redhat.com Link: https://lore.kernel.org/r/20211011053921.1198936-1-pasic@linux.ibm.com Signed-off-by: Michael S. Tsirkin mst@redhat.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/virtio/virtio.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
--- a/drivers/virtio/virtio.c +++ b/drivers/virtio/virtio.c @@ -222,6 +222,17 @@ static int virtio_dev_probe(struct devic driver_features_legacy = driver_features; }
+ /* + * Some devices detect legacy solely via F_VERSION_1. Write + * F_VERSION_1 to force LE config space accesses before FEATURES_OK for + * these when needed. + */ + if (drv->validate && !virtio_legacy_is_little_endian() + && device_features & BIT_ULL(VIRTIO_F_VERSION_1)) { + dev->features = BIT_ULL(VIRTIO_F_VERSION_1); + dev->config->finalize_features(dev); + } + if (device_features & (1ULL << VIRTIO_F_VERSION_1)) dev->features = driver_features & device_features; else
From: Stephen Boyd swboyd@chromium.org
commit 5d388fa01fa6eb310ac023a363a6cb216d9d8fe9 upstream.
If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic
*p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);
will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we subtract one from that making a large number that is then shifted more than the number of bits that fit into an unsigned long.
UBSAN reports this problem:
UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8 shift exponent 64 is too large for 64-bit type 'unsigned long' CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 nvmem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 component_bind_all+0xf0/0x264 msm_drm_bind+0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c component_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 really_probe+0x110/0x304 __driver_probe_device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv+0x90/0xdc __device_attach+0xc8/0x174 device_initial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 deferred_probe_work_func+0x7c/0xb8 process_one_work+0x128/0x21c process_scheduled_works+0x40/0x54 worker_thread+0x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20
Fix it by making sure there are any bits to mask out.
Fixes: 69aba7948cbe ("nvmem: Add a simple NVMEM framework for consumers") Cc: Douglas Anderson dianders@chromium.org Cc: stable@vger.kernel.org Signed-off-by: Stephen Boyd swboyd@chromium.org Signed-off-by: Srinivas Kandagatla srinivas.kandagatla@linaro.org Link: https://lore.kernel.org/r/20211013124511.18726-1-srinivas.kandagatla@linaro.... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/nvmem/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/nvmem/core.c +++ b/drivers/nvmem/core.c @@ -987,7 +987,8 @@ static inline void nvmem_shift_read_buff *p-- = 0;
/* clear msb bits if any leftover in the last byte */ - *p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0); + if (cell->nbits % BITS_PER_BYTE) + *p &= GENMASK((cell->nbits % BITS_PER_BYTE) - 1, 0); }
static int __nvmem_cell_read(struct nvmem_device *nvmem,
From: Borislav Petkov bp@suse.de
commit 711885906b5c2df90746a51f4cd674f1ab9fbb1d upstream.
This Kconfig option was added initially so that memory encryption is enabled by default on machines which support it.
However, devices which have DMA masks that are less than the bit position of the encryption bit, aka C-bit, require the use of an IOMMU or the use of SWIOTLB.
If the IOMMU is disabled or in passthrough mode, the kernel would switch to SWIOTLB bounce-buffering for those transfers.
In order to avoid that,
2cc13bb4f59f ("iommu: Disable passthrough mode when SME is active")
disables the default IOMMU passthrough mode so that devices for which the default 256K DMA is insufficient, can use the IOMMU instead.
However 2, there are cases where the IOMMU is disabled in the BIOS, etc. (think the usual hardware folk "oops, I dropped the ball there" cases) or a driver doesn't properly use the DMA APIs or a device has a firmware or hardware bug, e.g.:
ea68573d408f ("drm/amdgpu: Fail to load on RAVEN if SME is active")
However 3, in the above GPU use case, there are APIs like Vulkan and some OpenGL/OpenCL extensions which are under the assumption that user-allocated memory can be passed in to the kernel driver and both the GPU and CPU can do coherent and concurrent access to the same memory. That cannot work with SWIOTLB bounce buffers, of course.
So, in order for those devices to function, drop the "default y" for the SME by default active option so that users who want to have SME enabled, will need to either enable it in their config or use "mem_encrypt=on" on the kernel command line.
[ tlendacky: Generalize commit message. ]
Fixes: 7744ccdbc16f ("x86/mm: Add Secure Memory Encryption (SME) support") Reported-by: Paul Menzel pmenzel@molgen.mpg.de Signed-off-by: Borislav Petkov bp@suse.de Acked-by: Alex Deucher alexander.deucher@amd.com Acked-by: Tom Lendacky thomas.lendacky@amd.com Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/8bbacd0e-4580-3194-19d2-a0ecad7df09c@molgen.mpg.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- arch/x86/Kconfig | 1 - 1 file changed, 1 deletion(-)
--- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1456,7 +1456,6 @@ config AMD_MEM_ENCRYPT
config AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT bool "Activate AMD Secure Memory Encryption (SME) by default" - default y depends on AMD_MEM_ENCRYPT ---help--- Say yes to have system memory encrypted by default if running on
From: Billy Tsai billy_tsai@aspeedtech.com
commit eb795cd97365a3d3d9da3926d234a7bc32a3bb15 upstream.
Fix the issue when adc remove will get the null driver data.
Fixed: commit 573803234e72 ("iio: Aspeed ADC") Signed-off-by: Billy Tsai billy_tsai@aspeedtech.com Link: https://lore.kernel.org/r/20210831071458.2334-2-billy_tsai@aspeedtech.com Cc: Stable@vger.kernel.org Signed-off-by: Jonathan Cameron Jonathan.Cameron@huawei.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/iio/adc/aspeed_adc.c | 1 + 1 file changed, 1 insertion(+)
--- a/drivers/iio/adc/aspeed_adc.c +++ b/drivers/iio/adc/aspeed_adc.c @@ -187,6 +187,7 @@ static int aspeed_adc_probe(struct platf
data = iio_priv(indio_dev); data->dev = &pdev->dev; + platform_set_drvdata(pdev, indio_dev);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0); data->base = devm_ioremap_resource(&pdev->dev, res);
From: Christophe JAILLET christophe.jaillet@wanadoo.fr
commit bbcf40816b547b3c37af49168950491d20d81ce1 upstream.
A successful 'regulator_enable()' call should be balanced by a corresponding 'regulator_disable()' call in the error handling path of the probe, as already done in the remove function.
Update the error handling path accordingly.
Fixes: 913b86468674 ("iio: adc: Add TI ADC128S052") Signed-off-by: Christophe JAILLET christophe.jaillet@wanadoo.fr Reviewed-by: Alexandru Ardelean ardeleanalex@gmail.com Link: https://lore.kernel.org/r/85189f1cfcf6f5f7b42d8730966f2a074b07b5f5.162954216... Cc: Stable@vger.kernel.org Signed-off-by: Jonathan Cameron Jonathan.Cameron@huawei.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/iio/adc/ti-adc128s052.c | 6 ++++++ 1 file changed, 6 insertions(+)
--- a/drivers/iio/adc/ti-adc128s052.c +++ b/drivers/iio/adc/ti-adc128s052.c @@ -169,7 +169,13 @@ static int adc128_probe(struct spi_devic mutex_init(&adc->lock);
ret = iio_device_register(indio_dev); + if (ret) + goto err_disable_regulator;
+ return 0; + +err_disable_regulator: + regulator_disable(adc->reg); return ret; }
From: Jiri Valek - 2N valek@2n.cz
commit 26d90b5590579def54382a2fc34cfbe8518a9851 upstream.
Reading from sensor returned timeout error under zero light conditions.
Signed-off-by: Jiri Valek - 2N valek@2n.cz Fixes: ac663db3678a ("iio: light: opt3001: enable operation w/o IRQ") Link: https://lore.kernel.org/r/20210920125351.6569-1-valek@2n.cz Cc: Stable@vger.kernel.org Signed-off-by: Jonathan Cameron Jonathan.Cameron@huawei.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/iio/light/opt3001.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/iio/light/opt3001.c +++ b/drivers/iio/light/opt3001.c @@ -283,6 +283,8 @@ static int opt3001_get_lux(struct opt300 ret = wait_event_timeout(opt->result_ready_queue, opt->result_ready, msecs_to_jiffies(OPT3001_RESULT_READY_LONG)); + if (ret == 0) + return -ETIMEDOUT; } else { /* Sleep for result ready time */ timeout = (opt->int_time == OPT3001_INT_TIME_SHORT) ? @@ -319,9 +321,7 @@ err: /* Disallow IRQ to access the device while lock is active */ opt->ok_to_ignore_lock = false;
- if (ret == 0) - return -ETIMEDOUT; - else if (ret < 0) + if (ret < 0) return ret;
if (opt->use_irq) {
From: Dan Carpenter dan.carpenter@oracle.com
commit 8167c9a375ccceed19048ad9d68cb2d02ed276e0 upstream.
The "idx" is validated at the start of the loop but it gets incremented during the iteration so it needs to be checked again.
Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") Signed-off-by: Dan Carpenter dan.carpenter@oracle.com Link: https://lore.kernel.org/r/20210909091336.GA26312@kili Cc: Stable@vger.kernel.org Signed-off-by: Jonathan Cameron Jonathan.Cameron@huawei.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/iio/common/ssp_sensors/ssp_spi.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
--- a/drivers/iio/common/ssp_sensors/ssp_spi.c +++ b/drivers/iio/common/ssp_sensors/ssp_spi.c @@ -286,6 +286,8 @@ static int ssp_parse_dataframe(struct ss for (idx = 0; idx < len;) { switch (dataframe[idx++]) { case SSP_MSG2AP_INST_BYPASS_DATA: + if (idx >= len) + return -EPROTO; sd = dataframe[idx++]; if (sd < 0 || sd >= SSP_SENSOR_MAX) { dev_err(SSP_DEV, @@ -295,10 +297,13 @@ static int ssp_parse_dataframe(struct ss
if (indio_devs[sd]) { spd = iio_priv(indio_devs[sd]); - if (spd->process_data) + if (spd->process_data) { + if (idx >= len) + return -EPROTO; spd->process_data(indio_devs[sd], &dataframe[idx], data->timestamp); + } } else { dev_err(SSP_DEV, "no client for frame\n"); } @@ -306,6 +311,8 @@ static int ssp_parse_dataframe(struct ss idx += ssp_offset_map[sd]; break; case SSP_MSG2AP_INST_DEBUG_DATA: + if (idx >= len) + return -EPROTO; sd = ssp_print_mcu_debug(dataframe, &idx, len); if (sd) { dev_err(SSP_DEV,
From: Dan Carpenter dan.carpenter@oracle.com
commit 4170d3dd1467e9d78cb9af374b19357dc324b328 upstream.
The ssp_print_mcu_debug() function should return negative error codes on error. Returning "length" is meaningless. This change does not affect runtime because the callers only care about zero/non-zero.
Reported-by: Jonathan Cameron jic23@kernel.org Fixes: 50dd64d57eee ("iio: common: ssp_sensors: Add sensorhub driver") Signed-off-by: Dan Carpenter dan.carpenter@oracle.com Link: https://lore.kernel.org/r/20210914105333.GA11657@kili Cc: Stable@vger.kernel.org Signed-off-by: Jonathan Cameron Jonathan.Cameron@huawei.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/iio/common/ssp_sensors/ssp_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iio/common/ssp_sensors/ssp_spi.c +++ b/drivers/iio/common/ssp_sensors/ssp_spi.c @@ -147,7 +147,7 @@ static int ssp_print_mcu_debug(char *dat if (length > received_len - *data_index || length <= 0) { ssp_dbg("[SSP]: MSG From MCU-invalid debug length(%d/%d)\n", length, received_len); - return length ? length : -EPROTO; + return -EPROTO; }
ssp_dbg("[SSP]: MSG From MCU - %s\n", &data_frame[*data_index]);
From: Eiichi Tsukata eiichi.tsukata@nutanix.com
commit a2d859e3fc97e79d907761550dbc03ff1b36479c upstream.
sctp_make_strreset_req() makes repeated calls to sctp_addto_chunk() which will automatically account for padding on each call. inreq and outreq are already 4 bytes aligned, but the payload is not and doing SCTP_PAD4(a + b) (which _sctp_make_chunk() did implicitly here) is different from SCTP_PAD4(a) + SCTP_PAD4(b) and not enough. It led to possible attempt to use more buffer than it was allocated and triggered a BUG_ON.
Cc: Vlad Yasevich vyasevich@gmail.com Cc: Neil Horman nhorman@tuxdriver.com Cc: Greg KH gregkh@linuxfoundation.org Fixes: cc16f00f6529 ("sctp: add support for generating stream reconf ssn reset request chunk") Reported-by: Eiichi Tsukata eiichi.tsukata@nutanix.com Signed-off-by: Eiichi Tsukata eiichi.tsukata@nutanix.com Signed-off-by: Marcelo Ricardo Leitner marcelo.leitner@gmail.com Signed-off-by: Marcelo Ricardo Leitner mleitner@redhat.com Reviewed-by: Xin Long lucien.xin@gmail.com Link: https://lore.kernel.org/r/b97c1f8b0c7ff79ac4ed206fc2c49d3612e0850c.163415684... Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/sctp/sm_make_chunk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/sctp/sm_make_chunk.c +++ b/net/sctp/sm_make_chunk.c @@ -3623,7 +3623,7 @@ struct sctp_chunk *sctp_make_strreset_re outlen = (sizeof(outreq) + stream_len) * out; inlen = (sizeof(inreq) + stream_len) * in;
- retval = sctp_make_reconf(asoc, outlen + inlen); + retval = sctp_make_reconf(asoc, SCTP_PAD4(outlen) + SCTP_PAD4(inlen)); if (!retval) return NULL;
From: Vegard Nossum vegard.nossum@oracle.com
commit e599ee234ad4fdfe241d937bbabd96e0d8f9d868 upstream.
Fix the following build/link error by adding a dependency on the CRC32 routines:
ld: drivers/net/ethernet/arc/emac_main.o: in function `arc_emac_set_rx_mode': emac_main.c:(.text+0xb11): undefined reference to `crc32_le'
The crc32_le() call comes through the ether_crc_le() call in arc_emac_set_rx_mode().
[v2: moved the select to ARC_EMAC_CORE; the Makefile is a bit confusing, but the error comes from emac_main.o, which is part of the arc_emac module, which in turn is enabled by CONFIG_ARC_EMAC_CORE. Note that arc_emac is different from emac_arc...]
Fixes: 775dd682e2b0ec ("arc_emac: implement promiscuous mode and multicast filtering") Cc: Arnd Bergmann arnd@arndb.de Signed-off-by: Vegard Nossum vegard.nossum@oracle.com Link: https://lore.kernel.org/r/20211012093446.1575-1-vegard.nossum@oracle.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/net/ethernet/arc/Kconfig | 1 + 1 file changed, 1 insertion(+)
--- a/drivers/net/ethernet/arc/Kconfig +++ b/drivers/net/ethernet/arc/Kconfig @@ -20,6 +20,7 @@ config ARC_EMAC_CORE depends on ARC || ARCH_ROCKCHIP || COMPILE_TEST select MII select PHYLIB + select CRC32
config ARC_EMAC tristate "ARC EMAC support"
From: Vegard Nossum vegard.nossum@oracle.com
commit 427f974d9727ca681085ddcd0530c97ab5811ae0 upstream.
Fix the following build/link error by adding a dependency on the CRC32 routines:
ld: drivers/net/ethernet/korina.o: in function `korina_multicast_list': korina.c:(.text+0x1af): undefined reference to `crc32_le'
Fixes: ef11291bcd5f9 ("Add support the Korina (IDT RC32434) Ethernet MAC") Cc: Arnd Bergmann arnd@arndb.de Signed-off-by: Vegard Nossum vegard.nossum@oracle.com Acked-by: Florian fainelli f.fainelli@gmail.com Link: https://lore.kernel.org/r/20211012152509.21771-1-vegard.nossum@oracle.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/net/ethernet/Kconfig | 1 + 1 file changed, 1 insertion(+)
--- a/drivers/net/ethernet/Kconfig +++ b/drivers/net/ethernet/Kconfig @@ -99,6 +99,7 @@ config JME config KORINA tristate "Korina (IDT RC32434) Ethernet support" depends on MIKROTIK_RB532 + select CRC32 ---help--- If you have a Mikrotik RouterBoard 500 or IDT RC32434 based system say Y. Otherwise say N.
From: Nanyong Sun sunnanyong@huawei.com
commit f03dca0c9e2297c84a018e306f8a9cd534ee4287 upstream.
devm_regmap_init may return error which caused by like out of memory, this will results in null pointer dereference later when reading or writing register:
general protection fault in encx24j600_spi_probe KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540 Code: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00 RSP: 0018:ffffc900010476b8 EFLAGS: 00010207 RAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 0000000000000000 RDX: 0000000000000012 RSI: ffff888002de0000 RDI: 0000000000000094 RBP: ffff888013c9a000 R08: 0000000000000000 R09: fffffbfff3f9cc6a R10: ffffc900010476e8 R11: fffffbfff3f9cc69 R12: 0000000000000001 R13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08 FS: 00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459 spi_probe drivers/spi/spi.c:397 really_probe drivers/base/dd.c:517 __driver_probe_device drivers/base/dd.c:751 driver_probe_device drivers/base/dd.c:782 __device_attach_driver drivers/base/dd.c:899 bus_for_each_drv drivers/base/bus.c:427 __device_attach drivers/base/dd.c:971 bus_probe_device drivers/base/bus.c:487 device_add drivers/base/core.c:3364 __spi_add_device drivers/spi/spi.c:599 spi_add_device drivers/spi/spi.c:641 spi_new_device drivers/spi/spi.c:717 new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d00630982840568e85e] dev_attr_store drivers/base/core.c:2074 sysfs_kf_write fs/sysfs/file.c:139 kernfs_fop_write_iter fs/kernfs/file.c:300 new_sync_write fs/read_write.c:508 (discriminator 4) vfs_write fs/read_write.c:594 ksys_write fs/read_write.c:648 do_syscall_64 arch/x86/entry/common.c:50 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113
Add error check in devm_regmap_init_encx24j600 to avoid this situation.
Fixes: 04fbfce7a222 ("net: Microchip encx24j600 driver") Reported-by: Hulk Robot hulkci@huawei.com Signed-off-by: Nanyong Sun sunnanyong@huawei.com Link: https://lore.kernel.org/r/20211012125901.3623144-1-sunnanyong@huawei.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/net/ethernet/microchip/encx24j600-regmap.c | 10 ++++++++-- drivers/net/ethernet/microchip/encx24j600.c | 5 ++++- drivers/net/ethernet/microchip/encx24j600_hw.h | 4 ++-- 3 files changed, 14 insertions(+), 5 deletions(-)
--- a/drivers/net/ethernet/microchip/encx24j600-regmap.c +++ b/drivers/net/ethernet/microchip/encx24j600-regmap.c @@ -505,13 +505,19 @@ static struct regmap_bus phymap_encx24j6 .reg_read = regmap_encx24j600_phy_reg_read, };
-void devm_regmap_init_encx24j600(struct device *dev, - struct encx24j600_context *ctx) +int devm_regmap_init_encx24j600(struct device *dev, + struct encx24j600_context *ctx) { mutex_init(&ctx->mutex); regcfg.lock_arg = ctx; ctx->regmap = devm_regmap_init(dev, ®map_encx24j600, ctx, ®cfg); + if (IS_ERR(ctx->regmap)) + return PTR_ERR(ctx->regmap); ctx->phymap = devm_regmap_init(dev, &phymap_encx24j600, ctx, &phycfg); + if (IS_ERR(ctx->phymap)) + return PTR_ERR(ctx->phymap); + + return 0; } EXPORT_SYMBOL_GPL(devm_regmap_init_encx24j600);
--- a/drivers/net/ethernet/microchip/encx24j600.c +++ b/drivers/net/ethernet/microchip/encx24j600.c @@ -1032,10 +1032,13 @@ static int encx24j600_spi_probe(struct s priv->speed = SPEED_100;
priv->ctx.spi = spi; - devm_regmap_init_encx24j600(&spi->dev, &priv->ctx); ndev->irq = spi->irq; ndev->netdev_ops = &encx24j600_netdev_ops;
+ ret = devm_regmap_init_encx24j600(&spi->dev, &priv->ctx); + if (ret) + goto out_free; + mutex_init(&priv->lock);
/* Reset device and check if it is connected */ --- a/drivers/net/ethernet/microchip/encx24j600_hw.h +++ b/drivers/net/ethernet/microchip/encx24j600_hw.h @@ -15,8 +15,8 @@ struct encx24j600_context { int bank; };
-void devm_regmap_init_encx24j600(struct device *dev, - struct encx24j600_context *ctx); +int devm_regmap_init_encx24j600(struct device *dev, + struct encx24j600_context *ctx);
/* Single-byte instructions */ #define BANK_SELECT(bank) (0xC0 | ((bank & (BANK_MASK >> BANK_SHIFT)) << 1))
From: Arnd Bergmann arnd@arndb.de
commit 40507e7aada8422c38aafa0c8a1a09e4623c712a upstream.
After recent cleanups, gcc started warning about a suspicious memcpy() call during the s2io_io_resume() function:
In function '__dev_addr_set', inlined from 'eth_hw_addr_set' at include/linux/etherdevice.h:318:2, inlined from 's2io_set_mac_addr' at drivers/net/ethernet/neterion/s2io.c:5205:2, inlined from 's2io_io_resume' at drivers/net/ethernet/neterion/s2io.c:8569:7: arch/x86/include/asm/string_32.h:182:25: error: '__builtin_memcpy' accessing 6 bytes at offsets 0 and 2 overlaps 4 bytes at offset 2 [-Werror=restrict] 182 | #define memcpy(t, f, n) __builtin_memcpy(t, f, n) | ^~~~~~~~~~~~~~~~~~~~~~~~~ include/linux/netdevice.h:4648:9: note: in expansion of macro 'memcpy' 4648 | memcpy(dev->dev_addr, addr, len); | ^~~~~~
What apparently happened is that an old cleanup changed the calling conventions for s2io_set_mac_addr() from taking an ethernet address as a character array to taking a struct sockaddr, but one of the callers was not changed at the same time.
Change it to instead call the low-level do_s2io_prog_unicast() function that still takes the old argument type.
Fixes: 2fd376884558 ("S2io: Added support set_mac_address driver entry point") Signed-off-by: Arnd Bergmann arnd@arndb.de Link: https://lore.kernel.org/r/20211013143613.2049096-1-arnd@kernel.org Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/net/ethernet/neterion/s2io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/neterion/s2io.c +++ b/drivers/net/ethernet/neterion/s2io.c @@ -8574,7 +8574,7 @@ static void s2io_io_resume(struct pci_de return; }
- if (s2io_set_mac_addr(netdev, netdev->dev_addr) == FAILURE) { + if (do_s2io_prog_unicast(netdev, netdev->dev_addr) == FAILURE) { s2io_card_down(sp); pr_err("Can't restore mac addr after reset.\n"); return;
From: Ziyang Xuan william.xuanziyang@huawei.com
commit 0911ab31896f0e908540746414a77dd63912748d upstream.
When nfc proto id is using, nfc_proto_register() return -EBUSY error code, but forgot to unregister proto. Fix it by adding proto_unregister() in the error handling case.
Fixes: c7fe3b52c128 ("NFC: add NFC socket family") Signed-off-by: Ziyang Xuan william.xuanziyang@huawei.com Reviewed-by: Krzysztof Kozlowski krzysztof.kozlowski@canonical.com Link: https://lore.kernel.org/r/20211013034932.2833737-1-william.xuanziyang@huawei... Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/nfc/af_nfc.c | 3 +++ 1 file changed, 3 insertions(+)
--- a/net/nfc/af_nfc.c +++ b/net/nfc/af_nfc.c @@ -72,6 +72,9 @@ int nfc_proto_register(const struct nfc_ proto_tab[nfc_proto->id] = nfc_proto; write_unlock(&proto_tab_lock);
+ if (rc) + proto_unregister(nfc_proto->proto); + return rc; } EXPORT_SYMBOL(nfc_proto_register);
From: Ziyang Xuan william.xuanziyang@huawei.com
commit 58e7dcc9ca29c14e44267a4d0ea61e3229124907 upstream.
'params' is allocated in digital_tg_listen_mdaa(), but not free when digital_send_cmd() failed, which will cause memory leak. Fix it by freeing 'params' if digital_send_cmd() return failed.
Fixes: 1c7a4c24fbfd ("NFC Digital: Add target NFC-DEP support") Signed-off-by: Ziyang Xuan william.xuanziyang@huawei.com Reviewed-by: Krzysztof Kozlowski krzysztof.kozlowski@canonical.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/nfc/digital_core.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
--- a/net/nfc/digital_core.c +++ b/net/nfc/digital_core.c @@ -286,6 +286,7 @@ int digital_tg_configure_hw(struct nfc_d static int digital_tg_listen_mdaa(struct nfc_digital_dev *ddev, u8 rf_tech) { struct digital_tg_mdaa_params *params; + int rc;
params = kzalloc(sizeof(*params), GFP_KERNEL); if (!params) @@ -300,8 +301,12 @@ static int digital_tg_listen_mdaa(struct get_random_bytes(params->nfcid2 + 2, NFC_NFCID2_MAXSIZE - 2); params->sc = DIGITAL_SENSF_FELICA_SC;
- return digital_send_cmd(ddev, DIGITAL_CMD_TG_LISTEN_MDAA, NULL, params, - 500, digital_tg_recv_atr_req, NULL); + rc = digital_send_cmd(ddev, DIGITAL_CMD_TG_LISTEN_MDAA, NULL, params, + 500, digital_tg_recv_atr_req, NULL); + if (rc) + kfree(params); + + return rc; }
static int digital_tg_listen_md(struct nfc_digital_dev *ddev, u8 rf_tech)
From: Ziyang Xuan william.xuanziyang@huawei.com
commit 291c932fc3692e4d211a445ba8aa35663831bac7 upstream.
'skb' is allocated in digital_in_send_sdd_req(), but not free when digital_in_send_cmd() failed, which will cause memory leak. Fix it by freeing 'skb' if digital_in_send_cmd() return failed.
Fixes: 2c66daecc409 ("NFC Digital: Add NFC-A technology support") Signed-off-by: Ziyang Xuan william.xuanziyang@huawei.com Reviewed-by: Krzysztof Kozlowski krzysztof.kozlowski@canonical.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/nfc/digital_technology.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
--- a/net/nfc/digital_technology.c +++ b/net/nfc/digital_technology.c @@ -474,8 +474,12 @@ static int digital_in_send_sdd_req(struc skb_put_u8(skb, sel_cmd); skb_put_u8(skb, DIGITAL_SDD_REQ_SEL_PAR);
- return digital_in_send_cmd(ddev, skb, 30, digital_in_recv_sdd_res, - target); + rc = digital_in_send_cmd(ddev, skb, 30, digital_in_recv_sdd_res, + target); + if (rc) + kfree_skb(skb); + + return rc; }
static void digital_in_recv_sens_res(struct nfc_digital_dev *ddev, void *arg,
From: Dan Carpenter dan.carpenter@oracle.com
commit 013923477cb311293df9079332cf8b806ed0e6f2 upstream.
The last byte of "pad" is used without being initialized.
Fixes: 55dba3120fbc ("libata: update ->data_xfer hook for ATAPI") Signed-off-by: Dan Carpenter dan.carpenter@oracle.com Signed-off-by: Damien Le Moal damien.lemoal@wdc.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/ata/pata_legacy.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/ata/pata_legacy.c +++ b/drivers/ata/pata_legacy.c @@ -329,7 +329,8 @@ static unsigned int pdc_data_xfer_vlb(st iowrite32_rep(ap->ioaddr.data_addr, buf, buflen >> 2);
if (unlikely(slop)) { - __le32 pad; + __le32 pad = 0; + if (rw == READ) { pad = cpu_to_le32(ioread32(ap->ioaddr.data_addr)); memcpy(buf + buflen - slop, &pad, slop); @@ -719,7 +720,8 @@ static unsigned int vlb32_data_xfer(stru ioread32_rep(ap->ioaddr.data_addr, buf, buflen >> 2);
if (unlikely(slop)) { - __le32 pad; + __le32 pad = 0; + if (rw == WRITE) { memcpy(&pad, buf + buflen - slop, slop); iowrite32(le32_to_cpu(pad), ap->ioaddr.data_addr);
From: Colin Ian King colin.king@canonical.com
commit 2133c4fc8e1348dcb752f267a143fe2254613b34 upstream.
The initialization of pointer dev dereferences pointer edp before edp is null checked, so there is a potential null pointer deference issue. Fix this by only dereferencing edp after edp has been null checked.
Addresses-Coverity: ("Dereference before null check") Fixes: ab5b0107ccf3 ("drm/msm: Initial add eDP support in msm drm driver (v5)") Signed-off-by: Colin Ian King colin.king@canonical.com Reviewed-by: Dmitry Baryshkov dmitry.baryshkov@linaro.org Link: https://lore.kernel.org/r/20210929121857.213922-1-colin.king@canonical.com Signed-off-by: Rob Clark robdclark@chromium.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/gpu/drm/msm/edp/edp_ctrl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c +++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c @@ -1090,7 +1090,7 @@ void msm_edp_ctrl_power(struct edp_ctrl int msm_edp_ctrl_init(struct msm_edp *edp) { struct edp_ctrl *ctrl = NULL; - struct device *dev = &edp->pdev->dev; + struct device *dev; int ret;
if (!edp) { @@ -1098,6 +1098,7 @@ int msm_edp_ctrl_init(struct msm_edp *ed return -EINVAL; }
+ dev = &edp->pdev->dev; ctrl = devm_kzalloc(dev, sizeof(*ctrl), GFP_KERNEL); if (!ctrl) return -ENOMEM;
From: Dan Carpenter dan.carpenter@oracle.com
commit c8f01ffc83923a91e8087aaa077de13354a7aa59 upstream.
This disables a lock which wasn't enabled and it does not disable the first lock in the array.
Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list") Signed-off-by: Dan Carpenter dan.carpenter@oracle.com Reviewed-by: Dmitry Baryshkov dmitry.baryshkov@linaro.org Link: https://lore.kernel.org/r/20211001123409.GG2283@kili Signed-off-by: Dmitry Baryshkov dmitry.baryshkov@linaro.org Signed-off-by: Rob Clark robdclark@chromium.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -442,7 +442,7 @@ static int dsi_bus_clk_enable(struct msm
return 0; err: - for (; i > 0; i--) + while (--i >= 0) clk_disable_unprepare(msm_host->bus_clks[i]);
return ret;
From: Jackie Liu liuyun01@kylinos.cn
commit 596143e3aec35c93508d6b7a05ddc999ee209b61 upstream.
Fix modpost Section mismatch error in next_platform_timer().
[...] WARNING: modpost: vmlinux.o(.text.unlikely+0x26e60): Section mismatch in reference from the function next_platform_timer() to the variable .init.data:acpi_gtdt_desc The function next_platform_timer() references the variable __initdata acpi_gtdt_desc. This is often because next_platform_timer lacks a __initdata annotation or the annotation of acpi_gtdt_desc is wrong.
WARNING: modpost: vmlinux.o(.text.unlikely+0x26e64): Section mismatch in reference from the function next_platform_timer() to the variable .init.data:acpi_gtdt_desc The function next_platform_timer() references the variable __initdata acpi_gtdt_desc. This is often because next_platform_timer lacks a __initdata annotation or the annotation of acpi_gtdt_desc is wrong.
ERROR: modpost: Section mismatches detected. Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them. make[1]: *** [scripts/Makefile.modpost:59: vmlinux.symvers] Error 1 make[1]: *** Deleting file 'vmlinux.symvers' make: *** [Makefile:1176: vmlinux] Error 2 [...]
Fixes: a712c3ed9b8a ("acpi/arm64: Add memory-mapped timer support in GTDT driver") Signed-off-by: Jackie Liu liuyun01@kylinos.cn Acked-by: Hanjun Guo guohanjun@huawei.com Link: https://lore.kernel.org/r/20210823092526.2407526-1-liu.yun@linux.dev Signed-off-by: Catalin Marinas catalin.marinas@arm.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/acpi/arm64/gtdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/acpi/arm64/gtdt.c +++ b/drivers/acpi/arm64/gtdt.c @@ -39,7 +39,7 @@ struct acpi_gtdt_descriptor {
static struct acpi_gtdt_descriptor acpi_gtdt_desc __initdata;
-static inline void *next_platform_timer(void *platform_timer) +static inline __init void *next_platform_timer(void *platform_timer) { struct acpi_gtdt_header *gh = platform_timer;
From: chongjiapeng jiapeng.chong@linux.alibaba.com
commit a5a14ea7b4e55604acb0dc9d88fdb4cb6945bc77 upstream.
The error code is missing in this code scenario, add the error code '-EINVAL' to the return value 'rc'.
Eliminate the follow smatch warning:
drivers/net/ethernet/qlogic/qed/qed_main.c:1298 qed_slowpath_start() warn: missing error code 'rc'.
Reported-by: Abaci Robot abaci@linux.alibaba.com Fixes: d51e4af5c209 ("qed: aRFS infrastructure support") Signed-off-by: chongjiapeng jiapeng.chong@linux.alibaba.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/net/ethernet/qlogic/qed/qed_main.c | 1 + 1 file changed, 1 insertion(+)
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c +++ b/drivers/net/ethernet/qlogic/qed/qed_main.c @@ -998,6 +998,7 @@ static int qed_slowpath_start(struct qed } else { DP_NOTICE(cdev, "Failed to acquire PTT for aRFS\n"); + rc = -EINVAL; goto err; } }
From: Vegard Nossum vegard.nossum@oracle.com
commit 9973a43012b6ad1720dbc4d5faf5302c28635b8c upstream.
Fix the following build/link errors by adding a dependency on CRYPTO, CRYPTO_HASH, CRYPTO_SHA256 and CRC32:
ld: drivers/net/usb/r8152.o: in function `rtl8152_fw_verify_checksum': r8152.c:(.text+0x2b2a): undefined reference to `crypto_alloc_shash' ld: r8152.c:(.text+0x2bed): undefined reference to `crypto_shash_digest' ld: r8152.c:(.text+0x2c50): undefined reference to `crypto_destroy_tfm' ld: drivers/net/usb/r8152.o: in function `_rtl8152_set_rx_mode': r8152.c:(.text+0xdcb0): undefined reference to `crc32_le'
Fixes: 9370f2d05a2a1 ("r8152: support request_firmware for RTL8153") Fixes: ac718b69301c7 ("net/usb: new driver for RTL8152") Signed-off-by: Vegard Nossum vegard.nossum@oracle.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/net/usb/Kconfig | 4 ++++ 1 file changed, 4 insertions(+)
--- a/drivers/net/usb/Kconfig +++ b/drivers/net/usb/Kconfig @@ -98,6 +98,10 @@ config USB_RTL8150 config USB_RTL8152 tristate "Realtek RTL8152/RTL8153 Based USB Ethernet Adapters" select MII + select CRC32 + select CRYPTO + select CRYPTO_HASH + select CRYPTO_SHA256 help This option adds support for Realtek RTL8152 based USB 2.0 10/100 Ethernet adapters and RTL8153 based USB 3.0 10/100/1000
On Mon, 18 Oct 2021 15:24:09 +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.252 release. There are 39 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, 20 Oct 2021 13:23:15 +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.14.252-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.14: 8 builds: 8 pass, 0 fail 16 boots: 16 pass, 0 fail 32 tests: 32 pass, 0 fail
Linux version: 4.14.252-rc1-gf772f5cdea86 Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04
Tested-by: Jon Hunter jonathanh@nvidia.com
Jon
On Mon, 18 Oct 2021 at 18:57, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.14.252 release. There are 39 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, 20 Oct 2021 13:23:15 +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.14.252-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.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 lkft@linaro.org
## Build * kernel: 4.14.252-rc1 * git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc * git branch: linux-4.14.y * git commit: f772f5cdea8646ee293bac8c4e702ad235969ecd * git describe: v4.14.250-74-gf772f5cdea86 * test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14....
## No regressions (compared to v4.14.251-7-g23de85e22f4d)
## No fixes (compared to v4.14.251-7-g23de85e22f4d)
## Test result summary total: 61585, pass: 48676, fail: 514, skip: 10650, xfail: 1745
## Build Summary * arm: 129 total, 129 passed, 0 failed * arm64: 34 total, 34 passed, 0 failed * i386: 17 total, 17 passed, 0 failed * mips: 24 total, 24 passed, 0 failed * sparc: 12 total, 12 passed, 0 failed * x86_64: 18 total, 18 passed, 0 failed
## Test suites summary * fwts * igt-gpu-tools * 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-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-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 * rcutorture * v4l2-compliance
-- Linaro LKFT https://lkft.linaro.org
On Mon, Oct 18, 2021 at 03:24:09PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.252 release. There are 39 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, 20 Oct 2021 13:23:15 +0000. Anything received after that time might be too late.
Build results: total: 163 pass: 163 fail: 0 Qemu test results: total: 394 pass: 394 fail: 0
Tested-by: Guenter Roeck linux@roeck-us.net
Guenter
On 2021/10/18 21:24, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.252 release. There are 39 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, 20 Oct 2021 13:23:15 +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.14.252-rc... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below.
thanks,
greg k-h
Tested on x86 for 4.14.252-rc1,
Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Branch: linux-4.14.y Version: 4.14.252-rc1 Commit: f772f5cdea8646ee293bac8c4e702ad235969ecd Compiler: gcc version 7.3.0 (GCC)
x86: -------------------------------------------------------------------- Testcase Result Summary: total: 8837 passed: 8837 failed: 0 timeout: 0 --------------------------------------------------------------------
Tested-by: Hulk Robot hulkrobot@huawei.com
linux-stable-mirror@lists.linaro.org
-
Greg Kroah-Hartman -
Guenter Roeck -
Jon Hunter -
Naresh Kamboju -
Samuel Zou