April 2022 - Linux-stable-mirror

[PATCH V5] mtd: rawnand: qcom: fix memory corruption that causes panic

by Md Sadre Alam

This patch fixes a memory corruption that occurred in the nand_scan() path for Hynix nand device. On boot, for Hynix nand device will panic at a weird place: | Unable to handle kernel NULL pointer dereference at virtual address 00000070 | [00000070] *pgd=00000000 | Internal error: Oops: 5 [#1] PREEMPT SMP ARM | Modules linked in: | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.0-01473-g13ae1769cfb0 #38 | Hardware name: Generic DT based system | PC is at nandc_set_reg+0x8/0x1c | LR is at qcom_nandc_command+0x20c/0x5d0 | pc : [<c088b74c>] lr : [<c088d9c8>] psr: 00000113 | sp : c14adc50 ip : c14ee208 fp : c0cc970c | r10: 000000a3 r9 : 00000000 r8 : 00000040 | r7 : c16f6a00 r6 : 00000090 r5 : 00000004 r4 :c14ee040 | r3 : 00000000 r2 : 0000000b r1 : 00000000 r0 :c14ee040 | Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none | Control: 10c5387d Table: 8020406a DAC: 00000051 | Register r0 information: slab kmalloc-2k start c14ee000 pointer offset 64 size 2048 | Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) | nandc_set_reg from qcom_nandc_command+0x20c/0x5d0 | qcom_nandc_command from nand_readid_op+0x198/0x1e8 | nand_readid_op from hynix_nand_has_valid_jedecid+0x30/0x78 | hynix_nand_has_valid_jedecid from hynix_nand_init+0xb8/0x454 | hynix_nand_init from nand_scan_with_ids+0xa30/0x14a8 | nand_scan_with_ids from qcom_nandc_probe+0x648/0x7b0 | qcom_nandc_probe from platform_probe+0x58/0xac The problem is that the nand_scan()'s qcom_nand_attach_chip callback is updating the nandc->max_cwperpage from 1 to 4 or 8 based on page size. This causes the sg_init_table of clear_bam_transaction() in the driver's qcom_nandc_command() to memset much more than what was initially allocated by alloc_bam_transaction(). This patch will update nandc->max_cwperpage 1 to 4 or 8 based on page size in qcom_nand_attach_chip call back after freeing the previously allocated memory for bam txn as per nandc->max_cwperpage = 1 and then again allocating bam txn as per nandc->max_cwperpage = 4 or 8 based on page size in qcom_nand_attach_chip call back itself. Cc: stable(a)vger.kernel.org Fixes: 6a3cec64f18c ("mtd: rawnand: qcom: convert driver to nand_scan()") Reported-by: Konrad Dybcio <konrad.dybcio(a)somainline.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> Co-developed-by: Sricharan R <quic_srichara(a)quicinc.com> Signed-off-by: Sricharan R <quic_srichara(a)quicinc.com> Signed-off-by: Md Sadre Alam <quic_mdalam(a)quicinc.com> --- Changes in V5: * Incorporated "missing Co-developed-by tag" comment from Mani * Added Co-developed-by tag Co-developed-by: Sricharan R <quic_srichara(a)quicinc.com> * Incorporated " Add Reviewed-by tag" comment from Mani * Added Reviewed-by tag Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> Changes in V4: * Incorporated "commit log wrong" comment from Mani * Updated commit log Changes in V3: * Incorporated "Fixes tags are missing" comment from Miquèl * Added Fixes tag Fixes:6a3cec64f18c ("mtd: rawnand: qcom: convert driver to nand_scan()") * Incorporated "stable tag missing" comment from Miquèl * Added stable tag Cc: stable(a)vger.kernel.org * Incorporated "Reported-by tag missing" comment from Mani * Added Reported-by tag Reported-by: Konrad Dybcio <konrad.dybcio(a)somainline.org> Changes in V2: * Incorporated "alloc_bam_transaction inside qcom_nand_attach_chip" suggestion from Mani * Freed previously alloacted memory for bam txn before updating max_cwperpage inside qcom_nand_attach_chip(). * Moved alloc_bam_transaction() inside qcom_nand_attach_chip(). after upding max_cwperpage 4 or 8 based on page size. drivers/mtd/nand/raw/qcom_nandc.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c index 1a77542..048b255 100644 --- a/drivers/mtd/nand/raw/qcom_nandc.c +++ b/drivers/mtd/nand/raw/qcom_nandc.c @@ -2651,10 +2651,23 @@ static int qcom_nand_attach_chip(struct nand_chip *chip) ecc->engine_type = NAND_ECC_ENGINE_TYPE_ON_HOST; mtd_set_ooblayout(mtd, &qcom_nand_ooblayout_ops); + /* Free the initially allocated BAM transaction for reading the ONFI params */ + if (nandc->props->is_bam) + free_bam_transaction(nandc); nandc->max_cwperpage = max_t(unsigned int, nandc->max_cwperpage, cwperpage); + /* Now allocate the BAM transaction based on updated max_cwperpage */ + if (nandc->props->is_bam) { + nandc->bam_txn = alloc_bam_transaction(nandc); + if (!nandc->bam_txn) { + dev_err(nandc->dev, + "failed to allocate bam transaction\n"); + return -ENOMEM; + } + } + /* * DATA_UD_BYTES varies based on whether the read/write command protects * spare data with ECC too. We protect spare data by default, so we set @@ -2955,17 +2968,6 @@ static int qcom_nand_host_init_and_register(struct qcom_nand_controller *nandc, if (ret) return ret; - if (nandc->props->is_bam) { - free_bam_transaction(nandc); - nandc->bam_txn = alloc_bam_transaction(nandc); - if (!nandc->bam_txn) { - dev_err(nandc->dev, - "failed to allocate bam transaction\n"); - nand_cleanup(chip); - return -ENOMEM; - } - } - ret = mtd_device_parse_register(mtd, probes, NULL, NULL, 0); if (ret) nand_cleanup(chip); -- 2.7.4

2 years, 5 months

2
1
0 0

[PATCH v2] pinctrl: samsung: fix missing GPIOLIB on ARM64 Exynos config

by Krzysztof Kozlowski

The Samsung pinctrl drivers depend on OF_GPIO, which is part of GPIOLIB. ARMv7 Exynos platform selects GPIOLIB and Samsung pinctrl drivers. ARMv8 Exynos selects only the latter leading to possible wrong configuration on ARMv8 build: WARNING: unmet direct dependencies detected for PINCTRL_EXYNOS Depends on [n]: PINCTRL [=y] && OF_GPIO [=n] && (ARCH_EXYNOS [=y] || ARCH_S5PV210 || COMPILE_TEST [=y]) Selected by [y]: - ARCH_EXYNOS [=y] Always select the GPIOLIB from the Samsung pinctrl drivers to fix the issue. This requires removing of OF_GPIO dependency (to avoid recursive dependency), so add dependency on OF for COMPILE_TEST cases. Reported-by: Necip Fazil Yildiran <fazilyildiran(a)gmail.com> Fixes: eed6b3eb20b9 ("arm64: Split out platform options to separate Kconfig") Cc: <stable(a)vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- Changes since v1: 1. Do not select OF_GPIO and add back dependency on OF (Arnd). Original report: https://bugzilla.kernel.org/show_bug.cgi?id=210047 --- arch/arm/mach-exynos/Kconfig | 1 - drivers/pinctrl/samsung/Kconfig | 11 ++++------- 2 files changed, 4 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 51a336f349f4..4d3b40e4049a 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -16,7 +16,6 @@ menuconfig ARCH_EXYNOS select EXYNOS_PMU select EXYNOS_SROM select EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS - select GPIOLIB select HAVE_ARM_ARCH_TIMER if ARCH_EXYNOS5 select HAVE_ARM_SCU if SMP select PINCTRL diff --git a/drivers/pinctrl/samsung/Kconfig b/drivers/pinctrl/samsung/Kconfig index dfd805e76862..7b0576f71376 100644 --- a/drivers/pinctrl/samsung/Kconfig +++ b/drivers/pinctrl/samsung/Kconfig @@ -4,14 +4,13 @@ # config PINCTRL_SAMSUNG bool - depends on OF_GPIO + select GPIOLIB select PINMUX select PINCONF config PINCTRL_EXYNOS bool "Pinctrl common driver part for Samsung Exynos SoCs" - depends on OF_GPIO - depends on ARCH_EXYNOS || ARCH_S5PV210 || COMPILE_TEST + depends on ARCH_EXYNOS || ARCH_S5PV210 || (COMPILE_TEST && OF) select PINCTRL_SAMSUNG select PINCTRL_EXYNOS_ARM if ARM && (ARCH_EXYNOS || ARCH_S5PV210) select PINCTRL_EXYNOS_ARM64 if ARM64 && ARCH_EXYNOS @@ -26,12 +25,10 @@ config PINCTRL_EXYNOS_ARM64 config PINCTRL_S3C24XX bool "Samsung S3C24XX SoC pinctrl driver" - depends on OF_GPIO - depends on ARCH_S3C24XX || COMPILE_TEST + depends on ARCH_S3C24XX || (COMPILE_TEST && OF) select PINCTRL_SAMSUNG config PINCTRL_S3C64XX bool "Samsung S3C64XX SoC pinctrl driver" - depends on OF_GPIO - depends on ARCH_S3C64XX || COMPILE_TEST + depends on ARCH_S3C64XX || (COMPILE_TEST && OF) select PINCTRL_SAMSUNG -- 2.32.0

2 years, 5 months

2
2
0 0

[PATCH 4/4] dt-bindings: sifive: add gpio-line-names

by Atul Khare

Fixes device tree schema validation messages like 'gpio-line-names' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: ... sifive,gpio.yaml'. The bindings were missing the gpio-line-names element, which was causing the dt-schema checker to trip-up. Fixes: a2770b57d083 ("dt-bindings: timer: Add CLINT bindings") Cc: stable(a)vger.kernel.org Signed-off-by: Atul Khare <atulkhare(a)rivosinc.com> --- Documentation/devicetree/bindings/gpio/sifive,gpio.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml index 427c5873f96a..0bdd39b7b3d5 100644 --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml @@ -47,6 +47,9 @@ properties: default: 16 gpio-controller: true + gpio-line-names: + minItems: 1 + maxItems: 32 required: - compatible -- 2.35.1

2 years, 5 months

1
0
0 0

[PATCH 3/4] dt-bindings: sifive: delete 'clock' / 'status'

by Atul Khare

Fixes device tree schema validation error messages like 'clocks does not match any of the regexes: 'pinctrl-[0-9]+''. The bindings for the memory element don't define the 'clock' and 'status' fields, and the presence of these elements was causing the dt-schema checker to trip-up. Our operating assumption is that the platform doesn't rely on the presence of these elements, and that they were introduced by a typographical oversight. Fixes: a2770b57d083 ("dt-bindings: timer: Add CLINT bindings") Cc: stable(a)vger.kernel.org Signed-off-by: Atul Khare <atulkhare(a)rivosinc.com> --- arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts | 4 ---- 1 file changed, 4 deletions(-) diff --git a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts index cd2fe80fa81a..0a498a0f7eeb 100644 --- a/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts +++ b/arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts @@ -32,15 +32,11 @@ cpus { ddrc_cache_lo: memory@80000000 { device_type = "memory"; reg = <0x0 0x80000000 0x0 0x2e000000>; - clocks = <&clkcfg CLK_DDRC>; - status = "okay"; }; ddrc_cache_hi: memory@1000000000 { device_type = "memory"; reg = <0x10 0x0 0x0 0x40000000>; - clocks = <&clkcfg CLK_DDRC>; - status = "okay"; }; }; -- 2.35.1

2 years, 5 months

1
0
0 0

[PATCH 2/4] dt-bindings: sifive: add cache-set value of 2048

by Atul Khare

Fixes Running device tree schema validation error messages like '... cache-sets:0:0: 1024 was expected'. The existing bindings had a single enumerated value of 1024, which trips up the dt-schema checks. The ISA permits any arbitrary power of two for the cache-sets value, but we decided to add the single additional value of 2048 because we couldn't spot an obvious way to express the constraint in the schema. Fixes: a2770b57d083 ("dt-bindings: timer: Add CLINT bindings") Cc: stable(a)vger.kernel.org Signed-off-by: Atul Khare <atulkhare(a)rivosinc.com> --- Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml index e2d330bd4608..309517b78e84 100644 --- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml +++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml @@ -46,7 +46,9 @@ properties: const: 2 cache-sets: - const: 1024 + # Note: Technically this can be any power of 2, but we didn't see an obvious way + # to express the constraint in Yaml + enum: [1024, 2048] cache-size: const: 2097152 -- 2.35.1

2 years, 5 months

1
0
0 0

[PATCH 1/4] dt-bindings: sifive: Support 1024 hart contexts

by Atul Khare

Fixes device tree schema validation error messages like 'clint@2000000: interrupts-extended: [[3, 3], [3, 7] ... is too long'. The CLINT bindings don't define an "interrupts-extended: maxItems", which trips up the dt-schema checks. Since there's no ISA-mandated limit, we arbitrarily chose 1024 to reflect the soon-to-be maximum of NR_CPUS=512 (systems typically have two hart contexts per CPU). Fixes: a2770b57d083 ("dt-bindings: timer: Add CLINT bindings") Cc: stable(a)vger.kernel.org Signed-off-by: Atul Khare <atulkhare(a)rivosinc.com> --- Documentation/devicetree/bindings/timer/sifive,clint.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml index 8d5f4687add9..4a1f6d422138 100644 --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml @@ -44,6 +44,8 @@ properties: interrupts-extended: minItems: 1 +# Based on updated max(NR_CPUS) (512) * (2 contexts per CPU) + maxItems: 1024 additionalProperties: false -- 2.35.1

2 years, 5 months

1
0
0 0

[PATCH 0/4] dt-bindings: sifive: fix dt-schema errors

by Atul Khare

The patch series fixes dt-schema validation errors that can be reproduced using the following: make ARCH=riscv defconfig; make ARCH=riscv dt_binding_check dtbs_check Atul Khare (4): dt-bindings: sifive: Support 1024 hart contexts dt-bindings: sifive: add cache-set value of 2048 dt-bindings: sifive: delete 'clock' / 'status' dt-bindings: sifive: add gpio-line-names Documentation/devicetree/bindings/gpio/sifive,gpio.yaml | 3 +++ Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml | 4 +++- Documentation/devicetree/bindings/timer/sifive,clint.yaml | 2 ++ arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts | 4 ---- 4 files changed, 8 insertions(+), 5 deletions(-) -- 2.35.1

2 years, 5 months

1
0
0 0

[PATCH v2] USB: serial: Fix heap overflow in WHITEHEAT_GET_DTR_RTS

by Kees Cook

The sizeof(struct whitehat_dr_info) can be 4 bytes under CONFIG_AEABI=n due to "-mabi=apcs-gnu", even though it has a single u8: whiteheat_private { __u8 mcr; /* 0 1 */ /* size: 4, cachelines: 1, members: 1 */ /* padding: 3 */ /* last cacheline: 4 bytes */ }; The result is technically harmless, as both the source and the destinations are currently the same allocation size (4 bytes) and don't use their padding, but if anything were to ever be added after the "mcr" member in "struct whiteheat_private", it would be overwritten. The structs both have a single u8 "mcr" member, but are 4 bytes in padded size. The memcpy() destination was explicitly targeting the u8 member (size 1) with the length of the whole structure (size 4), triggering the memcpy buffer overflow warning: In file included from include/linux/string.h:253, from include/linux/bitmap.h:11, from include/linux/cpumask.h:12, from include/linux/smp.h:13, from include/linux/lockdep.h:14, from include/linux/spinlock.h:62, from include/linux/mmzone.h:8, from include/linux/gfp.h:6, from include/linux/slab.h:15, from drivers/usb/serial/whiteheat.c:17: In function 'fortify_memcpy_chk', inlined from 'firm_send_command' at drivers/usb/serial/whiteheat.c:587:4: include/linux/fortify-string.h:328:25: warning: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning] 328 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Instead, just assign the one byte directly. Reported-by: kernel test robot <lkp(a)intel.com> Link: https://lore.kernel.org/lkml/202204142318.vDqjjSFn-lkp@intel.com Cc: Johan Hovold <johan(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: linux-usb(a)vger.kernel.org Cc: stable(a)vger.kernel.org Signed-off-by: Kees Cook <keescook(a)chromium.org> --- v1: https://lore.kernel.org/lkml/20220419041742.4117026-1-keescook@chromium.org/ v2: - just assign the single byte --- drivers/usb/serial/whiteheat.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/usb/serial/whiteheat.c b/drivers/usb/serial/whiteheat.c index da65d14c9ed5..06aad0d727dd 100644 --- a/drivers/usb/serial/whiteheat.c +++ b/drivers/usb/serial/whiteheat.c @@ -584,9 +584,8 @@ static int firm_send_command(struct usb_serial_port *port, __u8 command, switch (command) { case WHITEHEAT_GET_DTR_RTS: info = usb_get_serial_port_data(port); - memcpy(&info->mcr, command_info->result_buffer, - sizeof(struct whiteheat_dr_info)); - break; + info->mcr = command_info->result_buffer[0]; + break; } } exit: -- 2.32.0

2 years, 5 months

1
0
0 0

FAILED: patch "[PATCH] tracing: Dump stacktrace trigger to the corresponding" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ce33c845b030c9cf768370c951bc699470b09fa7 Mon Sep 17 00:00:00 2001 From: Daniel Bristot de Oliveira <bristot(a)kernel.org> Date: Sun, 20 Feb 2022 23:49:57 +0100 Subject: [PATCH] tracing: Dump stacktrace trigger to the corresponding instance The stacktrace event trigger is not dumping the stacktrace to the instance where it was enabled, but to the global "instance." Use the private_data, pointing to the trigger file, to figure out the corresponding trace instance, and use it in the trigger action, like snapshot_trigger does. Link: https://lkml.kernel.org/r/afbb0b4f18ba92c276865bc97204d438473f4ebc.16453962… Cc: stable(a)vger.kernel.org Fixes: ae63b31e4d0e2 ("tracing: Separate out trace events from global variables") Reviewed-by: Tom Zanussi <zanussi(a)kernel.org> Tested-by: Tom Zanussi <zanussi(a)kernel.org> Signed-off-by: Daniel Bristot de Oliveira <bristot(a)kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c index d00fee705f9c..e0d50c9577f3 100644 --- a/kernel/trace/trace_events_trigger.c +++ b/kernel/trace/trace_events_trigger.c @@ -1540,7 +1540,12 @@ stacktrace_trigger(struct event_trigger_data *data, struct trace_buffer *buffer, void *rec, struct ring_buffer_event *event) { - trace_dump_stack(STACK_SKIP); + struct trace_event_file *file = data->private_data; + + if (file) + __trace_stack(file->tr, tracing_gen_ctx(), STACK_SKIP); + else + trace_dump_stack(STACK_SKIP); } static void

2 years, 5 months

2
1
0 0

Hello

by Madi Zongo

-- Dear friend, My name is Madi Zongo, a banker in one of the banks in my country here called Burkina Faso. I have the sum of $27,2 Million for transfer which i need your help. If you are interested, please reply me urgently for more details. Contact me via Email: zmadizongo(a)gmail.com Thanks and best Regards.

2 years, 5 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2022