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

[6.17 stable request] netfilter: nft_ct: add seqadj extension for natted connections

by Florian Westphal

Hello Greg, hello Sasha, Could you please queue up 90918e3b6404 ("netfilter: nft_ct: add seqadj extension for natted connections") for 6.17? As-is some more esoteric configurations may not work and provide warning splat: Missing nfct_seqadj_ext_add() setup call WARNING: .. at net/netfilter/nf_conntrack_seqadj.c:41 ... [nf_conntrack] etc. I don't think this fix has risks and I'm not aware of any dependencies. Thanks for maintaining the stable trees!

4 days, 17 hours

2
1
0 0

⏰Gear up — less than 23 Hours Left to Secure Your VIP DUOONE OLED SPAN/FOLD Perk!

by InnLead Innovative

4 days, 17 hours

1
0
0 0

[PATCH v3 1/3] rpmsg: char: Remove put_device() in rpmsg_eptdev_add()

by Dawei Li

put_device() is called on error path of rpmsg_eptdev_add() to cleanup resource attached to eptdev->dev, unfortunately it's bogus cause dev->release() is not set yet. When a struct device instance is destroyed, driver core framework checks the possible release() callback from candidates below: - struct device::release() - dev->type->release() - dev->class->dev_release() Rpmsg eptdev owns none of them so WARN() will complaint the absence of release(): [ 159.112182] ------------[ cut here ]------------ [ 159.112188] Device '(null)' does not have a release() function, it is broken and must be fixed. See Documentation/core-api/kobject.rst. [ 159.112205] WARNING: CPU: 2 PID: 1975 at drivers/base/core.c:2567 device_release+0x7a/0x90 Fixes: c0cdc19f84a4 ("rpmsg: Driver for user space endpoint interface") Cc: stable(a)vger.kernel.org Signed-off-by: Dawei Li <dawei.li(a)linux.dev> --- drivers/rpmsg/rpmsg_char.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c index 34b35ea74aab..1b8297b373f0 100644 --- a/drivers/rpmsg/rpmsg_char.c +++ b/drivers/rpmsg/rpmsg_char.c @@ -494,7 +494,6 @@ static int rpmsg_eptdev_add(struct rpmsg_eptdev *eptdev, if (cdev) ida_free(&rpmsg_minor_ida, MINOR(dev->devt)); free_eptdev: - put_device(dev); kfree(eptdev); return ret; -- 2.25.1

4 days, 17 hours

2
3
0 0

[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

4 days, 17 hours

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

4 days, 18 hours

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

4 days, 19 hours

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

4 days, 19 hours

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

4 days, 20 hours

3
6
0 0

[PATCH V1 6.1.y 0/2] Fix bad pmd due to race between change_prot_numa() and THP migration

by Harry Yoo

# TL;DR previous discussion: https://lore.kernel.org/linux-mm/b41ea29e-6b48-4f64-859c-73be095453ae@redha… A "bad pmd" error occurs due to race condition between change_prot_numa() and THP migration. The mainline kernel does not have this bug as commit 670ddd8cdc fixes the race condition. 6.1.y, 5.15.y, 5.10.y, 5.4.y are affected by this bug. Fixing this in -stable kernels is tricky because pte_map_offset_lock() has different semantics in pre-6.5 and post-6.5 kernels. I am trying to backport the same mechanism we have in the mainline kernel. Since the code looks bit different due to different semantics of pte_map_offset_lock(), it'd be best to get this reviewed by MM folks. # Testing I verified that the bug described below is not reproduced anymore (on a downstream kernel) after applying this patch series. It used to trigger in few days of intensive numa balancing testing, but it survived 2 weeks with this applied. # Bug Description It was reported that a bad pmd is seen when automatic NUMA balancing is marking page table entries as prot_numa: [2437548.196018] mm/pgtable-generic.c:50: bad pmd 00000000af22fc02(dffffffe71fbfe02) [2437548.235022] Call Trace: [2437548.238234] <TASK> [2437548.241060] dump_stack_lvl+0x46/0x61 [2437548.245689] panic+0x106/0x2e5 [2437548.249497] pmd_clear_bad+0x3c/0x3c [2437548.253967] change_pmd_range.isra.0+0x34d/0x3a7 [2437548.259537] change_p4d_range+0x156/0x20e [2437548.264392] change_protection_range+0x116/0x1a9 [2437548.269976] change_prot_numa+0x15/0x37 [2437548.274774] task_numa_work+0x1b8/0x302 [2437548.279512] task_work_run+0x62/0x95 [2437548.283882] exit_to_user_mode_loop+0x1a4/0x1a9 [2437548.289277] exit_to_user_mode_prepare+0xf4/0xfc [2437548.294751] ? sysvec_apic_timer_interrupt+0x34/0x81 [2437548.300677] irqentry_exit_to_user_mode+0x5/0x25 [2437548.306153] asm_sysvec_apic_timer_interrupt+0x16/0x1b This is due to a race condition between change_prot_numa() and THP migration because the kernel doesn't check is_swap_pmd() and pmd_trans_huge() atomically: change_prot_numa() THP migration ====================================================================== - change_pmd_range() -> is_swap_pmd() returns false, meaning it's not a PMD migration entry. - do_huge_pmd_numa_page() -> migrate_misplaced_page() sets migration entries for the THP. - change_pmd_range() -> pmd_none_or_clear_bad_unless_trans_huge() -> pmd_none() and pmd_trans_huge() returns false - pmd_none_or_clear_bad_unless_trans_huge() -> pmd_bad() returns true for the migration entry! The upstream commit 670ddd8cdcbd ("mm/mprotect: delete pmd_none_or_clear_bad_unless_trans_huge()") closes this race condition by checking is_swap_pmd() and pmd_trans_huge() atomically. # Backporting note commit a79390f5d6a7 ("mm/mprotect: use long for page accountings and retval") is backported to return an error code (negative value) in change_pte_range(). Unlike the mainline, pte_offset_map_lock() does not check if the pmd entry is a migration entry or a hugepage; acquires PTL unconditionally instead of returning failure. Therefore, it is necessary to keep the !is_swap_pmd() && !pmd_trans_huge() && !pmd_devmap() checks in change_pmd_range() before acquiring the PTL. After acquiring the lock, open-code the semantics of pte_offset_map_lock() in the mainline kernel; change_pte_range() fails if the pmd value has changed. This requires adding pmd_old parameter (pmd_t value that is read before calling the function) to change_pte_range(). Hugh Dickins (1): mm/mprotect: delete pmd_none_or_clear_bad_unless_trans_huge() Peter Xu (1): mm/mprotect: use long for page accountings and retval include/linux/hugetlb.h | 4 +- include/linux/mm.h | 2 +- mm/hugetlb.c | 4 +- mm/mempolicy.c | 2 +- mm/mprotect.c | 125 ++++++++++++++++++---------------------- 5 files changed, 61 insertions(+), 76 deletions(-) -- 2.43.0

4 days, 20 hours

2
3
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

4 days, 20 hours

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror