- Linux-stable-mirror - lists.linaro.org

[PATCH v2] drm/xe: Prevent BIT() overflow when handling invalid prefetch region

by Shuicheng Lin

If user provides a large value (such as 0x80) for parameter prefetch_mem_region_instance in vm_bind ioctl, it will cause BIT(prefetch_region) overflow as below: " ------------[ cut here ]------------ UBSAN: shift-out-of-bounds in drivers/gpu/drm/xe/xe_vm.c:3414:7 shift exponent 128 is too large for 64-bit type 'long unsigned int' CPU: 8 UID: 0 PID: 53120 Comm: xe_exec_system_ Tainted: G W 6.18.0-rc1-lgci-xe-kernel+ #200 PREEMPT(voluntary) Tainted: [W]=WARN Hardware name: ASUS System Product Name/PRIME Z790-P WIFI, BIOS 0812 02/24/2023 Call Trace: <TASK> dump_stack_lvl+0xa0/0xc0 dump_stack+0x10/0x20 ubsan_epilogue+0x9/0x40 __ubsan_handle_shift_out_of_bounds+0x10e/0x170 ? mutex_unlock+0x12/0x20 xe_vm_bind_ioctl.cold+0x20/0x3c [xe] ... " Fix it by validating prefetch_region before the BIT() usage. v2: Add Closes and Cc stable kernels. (Matt) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6478 Cc: <stable(a)vger.kernel.org> # v6.8+ Reviewed-by: Matthew Auld <matthew.auld(a)intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin(a)intel.com> --- drivers/gpu/drm/xe/xe_vm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c index 8fb5cc6a69ec..7cac646bdf1c 100644 --- a/drivers/gpu/drm/xe/xe_vm.c +++ b/drivers/gpu/drm/xe/xe_vm.c @@ -3411,8 +3411,10 @@ static int vm_bind_ioctl_check_args(struct xe_device *xe, struct xe_vm *vm, op == DRM_XE_VM_BIND_OP_PREFETCH) || XE_IOCTL_DBG(xe, prefetch_region && op != DRM_XE_VM_BIND_OP_PREFETCH) || - XE_IOCTL_DBG(xe, (prefetch_region != DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC && - !(BIT(prefetch_region) & xe->info.mem_region_mask))) || + XE_IOCTL_DBG(xe, (prefetch_region != DRM_XE_CONSULT_MEM_ADVISE_PREF_LOC && + /* Guard against undefined shift in BIT(prefetch_region) */ + (prefetch_region >= (sizeof(xe->info.mem_region_mask) * 8) || + !(BIT(prefetch_region) & xe->info.mem_region_mask)))) || XE_IOCTL_DBG(xe, obj && op == DRM_XE_VM_BIND_OP_UNMAP) || XE_IOCTL_DBG(xe, (flags & DRM_XE_VM_BIND_FLAG_MADVISE_AUTORESET) && -- 2.49.0

1 week, 5 days

2
1
0 0

[PATCH] clk: tegra: tegra124-emc: Fix memory leak in load_timings_from_dt() on krealloc() failure

by Wentao Liang

The function load_timings_from_dt() directly assigns the result of krealloc() to tegra->timings, which causes a memory leak when krealloc() fails. When krealloc() returns NULL, the original pointer is lost, making it impossible to free the previously allocated memory. This fix uses a temporary variable to store the krealloc() result and only updates tegra->timings after successful allocation, preserving the original pointer in case of failure. Fixes: 888ca40e2843 ("clk: tegra: emc: Support multiple RAM codes") Cc: stable(a)vger.kernel.org Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- drivers/clk/tegra/clk-tegra124-emc.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/clk/tegra/clk-tegra124-emc.c b/drivers/clk/tegra/clk-tegra124-emc.c index 2a6db0434281..ed4972fa6dab 100644 --- a/drivers/clk/tegra/clk-tegra124-emc.c +++ b/drivers/clk/tegra/clk-tegra124-emc.c @@ -444,6 +444,7 @@ static int load_timings_from_dt(struct tegra_clk_emc *tegra, u32 ram_code) { struct emc_timing *timings_ptr; + struct emc_timing *new_timings; struct device_node *child; int child_count = of_get_child_count(node); int i = 0, err; @@ -451,10 +452,15 @@ static int load_timings_from_dt(struct tegra_clk_emc *tegra, size = (tegra->num_timings + child_count) * sizeof(struct emc_timing); - tegra->timings = krealloc(tegra->timings, size, GFP_KERNEL); - if (!tegra->timings) + new_timings = krealloc(tegra->timings, size, GFP_KERNEL); + if (!new_timings) { + kfree(tegra->timings); + tegra->timings = NULL; + tegra->num_timings = 0; return -ENOMEM; + } + tegra->timings = new_timings; timings_ptr = tegra->timings + tegra->num_timings; tegra->num_timings += child_count; -- 2.34.1

1 week, 5 days

3
2
0 0

[PATCH 1/2] ARM: dts: microchip: sama7d65: fix uart fifo size to 32

by nicolas.ferre＠microchip.com

From: Nicolas Ferre <nicolas.ferre(a)microchip.com> On some flexcom nodes related to uart, the fifo sizes were wrong: fix them to 32 data. Note that product datasheet is being reviewed to fix inconsistency, but this value is validated by product's designers. Fixes: 261dcfad1b59 ("ARM: dts: microchip: add sama7d65 SoC DT") Fixes: b51e4aea3ecf ("ARM: dts: microchip: sama7d65: Add FLEXCOMs to sama7d65 SoC") Cc: <stable(a)vger.kernel.org> # 6.16+ Signed-off-by: Nicolas Ferre <nicolas.ferre(a)microchip.com> --- arch/arm/boot/dts/microchip/sama7d65.dtsi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/boot/dts/microchip/sama7d65.dtsi b/arch/arm/boot/dts/microchip/sama7d65.dtsi index e53e2dd6d530..cd2cf9a6f40b 100644 --- a/arch/arm/boot/dts/microchip/sama7d65.dtsi +++ b/arch/arm/boot/dts/microchip/sama7d65.dtsi @@ -557,7 +557,7 @@ uart4: serial@200 { dma-names = "tx", "rx"; atmel,use-dma-rx; atmel,use-dma-tx; - atmel,fifo-size = <16>; + atmel,fifo-size = <32>; atmel,usart-mode = <AT91_USART_MODE_SERIAL>; status = "disabled"; }; @@ -618,7 +618,7 @@ uart6: serial@200 { clocks = <&pmc PMC_TYPE_PERIPHERAL 40>; clock-names = "usart"; atmel,usart-mode = <AT91_USART_MODE_SERIAL>; - atmel,fifo-size = <16>; + atmel,fifo-size = <32>; status = "disabled"; }; }; @@ -643,7 +643,7 @@ uart7: serial@200 { dma-names = "tx", "rx"; atmel,use-dma-rx; atmel,use-dma-tx; - atmel,fifo-size = <16>; + atmel,fifo-size = <32>; atmel,usart-mode = <AT91_USART_MODE_SERIAL>; status = "disabled"; }; -- 2.43.0

1 week, 5 days

2
3
0 0

[PATCH v2] atm/fore200e: Fix possible data race in fore200e_open()

by Gui-Dong Han

Protect access to fore200e->available_cell_rate with rate_mtx lock to prevent potential data race. In this case, since the update depends on a prior read, a data race could lead to a wrong fore200e.available_cell_rate value. The field fore200e.available_cell_rate is generally protected by the lock fore200e.rate_mtx when accessed. In all other read and write cases, this field is consistently protected by the lock, except for this case and during initialization. This potential bug was detected by our experimental static analysis tool, which analyzes locking APIs and paired functions to identify data races and atomicity violations. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Gui-Dong Han <2045gemini(a)gmail.com> --- v2: * Added a description of the data race hazard in fore200e_open(), as suggested by Jakub Kicinski and Simon Horman. --- drivers/atm/fore200e.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c index 4fea1149e003..f62e38571440 100644 --- a/drivers/atm/fore200e.c +++ b/drivers/atm/fore200e.c @@ -1374,7 +1374,9 @@ fore200e_open(struct atm_vcc *vcc) vcc->dev_data = NULL; + mutex_lock(&fore200e->rate_mtx); fore200e->available_cell_rate += vcc->qos.txtp.max_pcr; + mutex_unlock(&fore200e->rate_mtx); kfree(fore200e_vcc); return -EINVAL; -- 2.25.1

1 week, 5 days

3
5
0 0

[PATCH v2 0/1] Bluetooth: btqca: Add WCN6855 firmware priority selection feature

by Shuai Zhang

Fixed WCN6855 firmware to use the correct FW file and added a fallback mechanism. Changes v2: - Add Fixes tag. - Add comments in the commit and code to explain the reason for the changes. - Link to v1 https://lore.kernel.org/all/20251112074638.1592864-1-quic_shuaz@quicinc.com/ Shuai Zhang (1): Bluetooth: btqca: Add WCN6855 firmware priority selection feature drivers/bluetooth/btqca.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) -- 2.34.1

1 week, 5 days

3
6
0 0

[PATCH] nvmem: layouts: fix nvmem_layout_bus_uevent

by srini＠kernel.org

From: Wentao Guan <guanwentao(a)uniontech.com> correctly check the ENODEV return value. Fixes: 810b790033cc ("nvmem: layouts: fix automatic module loading") CC: stable(a)vger.kernel.org Co-developed-by: WangYuli <wangyl5933(a)chinaunicom.cn> Signed-off-by: WangYuli <wangyl5933(a)chinaunicom.cn> Signed-off-by: Wentao Guan <guanwentao(a)uniontech.com> Signed-off-by: Srinivas Kandagatla <srini(a)kernel.org> --- Hi Greg, There is only one nvmem fix in this cycle, Can you pl pick this fix for 6.18 release. thanks, --srini drivers/nvmem/layouts.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvmem/layouts.c b/drivers/nvmem/layouts.c index f381ce1e84bd..7ebe53249035 100644 --- a/drivers/nvmem/layouts.c +++ b/drivers/nvmem/layouts.c @@ -51,7 +51,7 @@ static int nvmem_layout_bus_uevent(const struct device *dev, int ret; ret = of_device_uevent_modalias(dev, env); - if (ret != ENODEV) + if (ret != -ENODEV) return ret; return 0; -- 2.51.0

1 week, 5 days

1
0
0 0

[PATCH] powerpc/powermac: Fix reference count leak in i2c probe functions

by Miaoqian Lin

The of_find_node_by_name() function returns a device tree node with its reference count incremented. The caller is responsible for calling of_node_put() to release this reference when done. Fixes: 730745a5c450 ("[PATCH] 1/5 powerpc: Rework PowerMac i2c part 1") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- arch/powerpc/platforms/powermac/low_i2c.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/powermac/low_i2c.c b/arch/powerpc/platforms/powermac/low_i2c.c index 02474e27df9b..f04dbb93bbfa 100644 --- a/arch/powerpc/platforms/powermac/low_i2c.c +++ b/arch/powerpc/platforms/powermac/low_i2c.c @@ -802,8 +802,10 @@ static void __init pmu_i2c_probe(void) for (channel = 1; channel <= 2; channel++) { sz = sizeof(struct pmac_i2c_bus) + sizeof(struct adb_request); bus = kzalloc(sz, GFP_KERNEL); - if (bus == NULL) + if (bus == NULL) { + of_node_put(busnode); return; + } bus->controller = busnode; bus->busnode = busnode; @@ -928,6 +930,7 @@ static void __init smu_i2c_probe(void) bus = kzalloc(sz, GFP_KERNEL); if (bus == NULL) { of_node_put(busnode); + of_node_put(controller); return; } -- 2.39.5 (Apple Git-154)

1 week, 5 days

2
1
0 0

[PATCH v4] arm64: dts: st: Add memory-region-names property for stm32mp257f-ev1

by Patrice Chotard

In order to set the AMCR register, which configures the memory-region split between ospi1 and ospi2, we need to identify the ospi instance. By using memory-region-names, it allows to identify the ospi instance this memory-region belongs to. Fixes: cad2492de91c ("arm64: dts: st: Add SPI NOR flash support on stm32mp257f-ev1 board") Cc: stable(a)vger.kernel.org Signed-off-by: Patrice Chotard <patrice.chotard(a)foss.st.com> --- Changes in v4: - Rebase on v6.18-rc1 - Link to v3: https://lore.kernel.org/r/20250811-upstream_fix_dts_omm-v3-1-c4186b7667cb@f… Changes in v3: - Set again "Cc: <stable(a)vger.kernel.org>" - Link to v2: https://lore.kernel.org/r/20250811-upstream_fix_dts_omm-v2-1-00ff55076bd5@f… Changes in v2: - Update commit message. - Use correct memory-region-names value. - Remove "Cc: <stable(a)vger.kernel.org>" tag as the fixed patch is not part of a LTS. - Link to v1: https://lore.kernel.org/r/20250806-upstream_fix_dts_omm-v1-1-e68c15ed422d@f… --- arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts index 6e165073f732..bb6d6393d2e4 100644 --- a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts +++ b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts @@ -266,6 +266,7 @@ &i2c8 { &ommanager { memory-region = <&mm_ospi1>; + memory-region-names = "ospi1"; pinctrl-0 = <&ospi_port1_clk_pins_a &ospi_port1_io03_pins_a &ospi_port1_cs0_pins_a>; --- base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787 change-id: 20250806-upstream_fix_dts_omm-c006b69042f1 Best regards, -- Patrice Chotard <patrice.chotard(a)foss.st.com>

1 week, 5 days

2
1
0 0

[PATCH v2] media: uvcvideo: Return queued buffers on start_streaming() failure

by Laurent Pinchart

From: Michal Pecio <michal.pecio(a)gmail.com> Return buffers if streaming fails to start due to uvc_pm_get() error. This bug may be responsible for a warning I got running while :; do yavta -c3 /dev/video0; done on an xHCI controller which failed under this workload. I had no luck reproducing this warning again to confirm. xhci_hcd 0000:09:00.0: HC died; cleaning up usb 13-2: USB disconnect, device number 2 WARNING: CPU: 2 PID: 29386 at drivers/media/common/videobuf2/videobuf2-core.c:1803 vb2_start_streaming+0xac/0x120 Fixes: 7dd56c47784a ("media: uvcvideo: Remove stream->is_streaming field") Cc: stable(a)vger.kernel.org Signed-off-by: Michal Pecio <michal.pecio(a)gmail.com> Reviewed-by: Ricardo Ribalda <ribalda(a)chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Link: https://patch.msgid.link/20251015133642.3dede646.michal.pecio@gmail.com Signed-off-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> --- Changes since v1: - Reorganize error path --- drivers/media/usb/uvc/uvc_queue.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/media/usb/uvc/uvc_queue.c b/drivers/media/usb/uvc/uvc_queue.c index 790184c9843d..e838c6c1893a 100644 --- a/drivers/media/usb/uvc/uvc_queue.c +++ b/drivers/media/usb/uvc/uvc_queue.c @@ -177,18 +177,20 @@ static int uvc_start_streaming_video(struct vb2_queue *vq, unsigned int count) ret = uvc_pm_get(stream->dev); if (ret) - return ret; + goto err_buffers; queue->buf_used = 0; ret = uvc_video_start_streaming(stream); - if (ret == 0) - return 0; + if (ret) + goto err_pm; + return 0; + +err_pm: uvc_pm_put(stream->dev); - +err_buffers: uvc_queue_return_buffers(queue, UVC_BUF_STATE_QUEUED); - return ret; } base-commit: d363bdfa0ec6b19a4f40b572cec70430d5b13ad6 -- Regards, Laurent Pinchart

1 week, 5 days

2
1
0 0

[PATCH 6.12.y] wifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error path

by jetlan9＠163.com

From: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> [ Upstream commit 68410c5bd381a81bcc92b808e7dc4e6b9ed25d11 ] If a shared IRQ is used by the driver due to platform limitation, then the IRQ affinity hint is set right after the allocation of IRQ vectors in ath11k_pci_alloc_msi(). This does no harm unless one of the functions requesting the IRQ fails and attempt to free the IRQ. This results in the below warning: WARNING: CPU: 7 PID: 349 at kernel/irq/manage.c:1929 free_irq+0x278/0x29c Call trace: free_irq+0x278/0x29c ath11k_pcic_free_irq+0x70/0x10c [ath11k] ath11k_pci_probe+0x800/0x820 [ath11k_pci] local_pci_probe+0x40/0xbc The warning is due to not clearing the affinity hint before freeing the IRQs. So to fix this issue, clear the IRQ affinity hint before calling ath11k_pcic_free_irq() in the error path. The affinity will be cleared once again further down the error path due to code organization, but that does no harm. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1 Cc: Baochen Qiang <quic_bqiang(a)quicinc.com> Fixes: 39564b475ac5 ("wifi: ath11k: fix boot failure with one MSI vector") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> Reviewed-by: Baochen Qiang <quic_bqiang(a)quicinc.com> Link: https://patch.msgid.link/20250225053447.16824-2-manivannan.sadhasivam@linar… Signed-off-by: Jeff Johnson <jeff.johnson(a)oss.qualcomm.com> Signed-off-by: Wenshan Lan <jetlan9(a)163.com> --- drivers/net/wireless/ath/ath11k/pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/ath/ath11k/pci.c b/drivers/net/wireless/ath/ath11k/pci.c index 6ebfa5d02e2e..c1d576ff77fa 100644 --- a/drivers/net/wireless/ath/ath11k/pci.c +++ b/drivers/net/wireless/ath/ath11k/pci.c @@ -936,6 +936,8 @@ static int ath11k_pci_probe(struct pci_dev *pdev, return 0; err_free_irq: + /* __free_irq() expects the caller to have cleared the affinity hint */ + ath11k_pci_set_irq_affinity_hint(ab_pci, NULL); ath11k_pcic_free_irq(ab); err_ce_free: -- 2.43.0

1 week, 5 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror