December 2024 - Linux-stable-mirror

[PATCH] drivers: clk: clk-en7523.c: Initialize num before accessing hws in en7523_register_clocks

by Haoyu Li

With the new __counted_by annocation in clk_hw_onecell_data, the "num" struct member must be set before accessing the "hws" array. Failing to do so will trigger a runtime warning when enabling CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE. Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") Signed-off-by: Haoyu Li <lihaoyu499(a)gmail.com> --- drivers/clk/clk-en7523.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/clk-en7523.c b/drivers/clk/clk-en7523.c index e52c5460e927..61d95ead5ec4 100644 --- a/drivers/clk/clk-en7523.c +++ b/drivers/clk/clk-en7523.c @@ -503,6 +503,8 @@ static void en7523_register_clocks(struct device *dev, struct clk_hw_onecell_dat u32 rate; int i; + clk_data->num = EN7523_NUM_CLOCKS; + for (i = 0; i < ARRAY_SIZE(en7523_base_clks); i++) { const struct en_clk_desc *desc = &en7523_base_clks[i]; u32 reg = desc->div_reg ? desc->div_reg : desc->base_reg; @@ -524,8 +526,6 @@ static void en7523_register_clocks(struct device *dev, struct clk_hw_onecell_dat hw = en7523_register_pcie_clk(dev, np_base); clk_data->hws[EN7523_CLK_PCIE] = hw; - - clk_data->num = EN7523_NUM_CLOCKS; } static int en7523_clk_hw_init(struct platform_device *pdev, -- 2.34.1

11 months, 1 week

3
2
0 0

Possible wrong fix patch for some stable branches

by Zhang Zekun

Hi, All The mainline patch to fix CVE-2024-50282 add a check to fix a potential buffer overflow issue in amdgpu_debugfs_gprwave_read() which is introduced in commit 553f973a0d7b ("drm/amd/amdgpu: Update debugfs for XCC support (v3)"), but some linux-stable fix patches add the check in some other funcitons, is something wrong here? Stable version which contain the suspicious patches: Fixed in 4.19.324 with commit 673bdb4200c0: Fixed in amdgpu_debugfs_regs_smc_read() Fixed in 5.4.286 with commit 7ccd781794d2: Fixed in amdgpu_debugfs_regs_smc_read() Fixed in 5.10.230 with commit 17f5f18085ac: Fixed in amdgpu_debugfs_regs_pcie_write() Fixed in 5.15.172 with commit aaf6160a4b7f: Fixed in amdgpu_debugfs_regs_didt_write() Fixed in 6.1.117 with commit 25d7e84343e1: Fixed in amdgpu_debugfs_regs_pcie_write() Link to mainline fix patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…

11 months, 1 week

4
3
0 0

[PATCH] KVM: arm64: Do not allow ID_AA64MMFR0_EL1.ASIDbits to be overridden

by Marc Zyngier

Catalin reports that a hypervisor lying to a guest about the size of the ASID field may result in unexpected issues: - if the underlying HW does only supports 8 bit ASIDs, the ASID field in a TLBI VAE1* operation is only 8 bits, and the HW will ignore the other 8 bits - if on the contrary the HW is 16 bit capable, the ASID field in the same TLBI operation is always 16 bits, irrespective of the value of TCR_ELx.AS. This could lead to missed invalidations if the guest was lead to assume that the HW had 8 bit ASIDs while they really are 16 bit wide. In order to avoid any potential disaster that would be hard to debug, prenent the migration between a host with 8 bit ASIDs to one with wider ASIDs (the converse was obviously always forbidden). This is also consistent with what we already do for VMIDs. If it becomes absolutely mandatory to support such a migration path in the future, we will have to trap and emulate all TLBIs, something that nobody should look forward to. Fixes: d5a32b60dc18 ("KVM: arm64: Allow userspace to change ID_AA64MMFR{0-2}_EL1") Reported-by: Catalin Marinas <catalin.marinas(a)arm.com> Signed-off-by: Marc Zyngier <maz(a)kernel.org> Cc: stable(a)vger.kernel.org Cc: Will Deacon <will(a)kernel.org> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: Marc Zyngier <maz(a)kernel.org> Cc: James Morse <james.morse(a)arm.com> Cc: Oliver Upton <oliver.upton(a)linux.dev> --- arch/arm64/kvm/sys_regs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c index a26f02ec8748..b1918adbd0aa 100644 --- a/arch/arm64/kvm/sys_regs.c +++ b/arch/arm64/kvm/sys_regs.c @@ -2674,7 +2674,8 @@ static const struct sys_reg_desc sys_reg_descs[] = { ID_WRITABLE(ID_AA64MMFR0_EL1, ~(ID_AA64MMFR0_EL1_RES0 | ID_AA64MMFR0_EL1_TGRAN4_2 | ID_AA64MMFR0_EL1_TGRAN64_2 | - ID_AA64MMFR0_EL1_TGRAN16_2)), + ID_AA64MMFR0_EL1_TGRAN16_2 | + ID_AA64MMFR0_EL1_ASIDBITS)), ID_WRITABLE(ID_AA64MMFR1_EL1, ~(ID_AA64MMFR1_EL1_RES0 | ID_AA64MMFR1_EL1_HCX | ID_AA64MMFR1_EL1_TWED | -- 2.43.0

11 months, 1 week

3
2
0 0

[PATCH v2] usb: typec: ucsi: Fix completion notifications

by Łukasz Bartosik

OPM PPM LPM | 1.send cmd | | |-------------------------->| | | |-- | | | | 2.set busy bit in CCI | | |<- | | 3.notify the OPM | | |<--------------------------| | | | 4.send cmd to be executed | | |-------------------------->| | | | | | 5.cmd completed | | |<--------------------------| | | | | |-- | | | | 6.set cmd completed | | |<- bit in CCI | | | | | 7.notify the OPM | | |<--------------------------| | | | | | 8.handle notification | | | from point 3, read CCI | | |<--------------------------| | | | | When the PPM receives command from the OPM (p.1) it sets the busy bit in the CCI (p.2), sends notification to the OPM (p.3) and forwards the command to be executed by the LPM (p.4). When the PPM receives command completion from the LPM (p.5) it sets command completion bit in the CCI (p.6) and sends notification to the OPM (p.7). If command execution by the LPM is fast enough then when the OPM starts handling the notification from p.3 in p.8 and reads the CCI value it will see command completion bit set and will call complete(). Then complete() might be called again when the OPM handles notification from p.7. This fix replaces test_bit() with test_and_clear_bit() in ucsi_notify_common() in order to call complete() only once per request. This fix also reinitializes completion variable in ucsi_sync_control_common() before a command is sent. Fixes: 584e8df58942 ("usb: typec: ucsi: extract common code for command handling") Cc: stable(a)vger.kernel.org Signed-off-by: Łukasz Bartosik <ukaszb(a)chromium.org> --- Changes in v2: - Swapped points 7 and 8 in the commit description in order to make diagram more clear. - Added reinitialization of completion variable in the ucsi_sync_control_common(). --- drivers/usb/typec/ucsi/ucsi.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c index c435c0835744..7a65a7672e18 100644 --- a/drivers/usb/typec/ucsi/ucsi.c +++ b/drivers/usb/typec/ucsi/ucsi.c @@ -46,11 +46,11 @@ void ucsi_notify_common(struct ucsi *ucsi, u32 cci) ucsi_connector_change(ucsi, UCSI_CCI_CONNECTOR(cci)); if (cci & UCSI_CCI_ACK_COMPLETE && - test_bit(ACK_PENDING, &ucsi->flags)) + test_and_clear_bit(ACK_PENDING, &ucsi->flags)) complete(&ucsi->complete); if (cci & UCSI_CCI_COMMAND_COMPLETE && - test_bit(COMMAND_PENDING, &ucsi->flags)) + test_and_clear_bit(COMMAND_PENDING, &ucsi->flags)) complete(&ucsi->complete); } EXPORT_SYMBOL_GPL(ucsi_notify_common); @@ -65,6 +65,8 @@ int ucsi_sync_control_common(struct ucsi *ucsi, u64 command) else set_bit(COMMAND_PENDING, &ucsi->flags); + reinit_completion(&ucsi->complete); + ret = ucsi->ops->async_control(ucsi, command); if (ret) goto out_clear_bit; -- 2.47.0.338.g60cca15819-goog

11 months, 1 week

4
5
0 0

[PATCH] bcache: revert replacing IS_ERR_OR_NULL with IS_ERR again

by Coly Li

From: Liequan Che <cheliequan(a)inspur.com> Commit 028ddcac477b ("bcache: Remove unnecessary NULL point check in node allocations") leads a NULL pointer deference in cache_set_flush(). 1721 if (!IS_ERR_OR_NULL(c->root)) 1722 list_add(&c->root->list, &c->btree_cache); From the above code in cache_set_flush(), if previous registration code fails before allocating c->root, it is possible c->root is NULL as what it is initialized. __bch_btree_node_alloc() never returns NULL but c->root is possible to be NULL at above line 1721. This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this. Fixes: 028ddcac477b ("bcache: Remove unnecessary NULL point check in node allocations") Signed-off-by: Liequan Che <cheliequan(a)inspur.com> Cc: stable(a)vger.kernel.org Cc: Zheng Wang <zyytlz.wz(a)163.com> Reviewed-by: Mingzhe Zou <mingzhe.zou(a)easystack.cn> Signed-off-by: Coly Li <colyli(a)suse.de> --- drivers/md/bcache/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c index e7abfdd77c3b..e42f1400cea9 100644 --- a/drivers/md/bcache/super.c +++ b/drivers/md/bcache/super.c @@ -1718,7 +1718,7 @@ static CLOSURE_CALLBACK(cache_set_flush) if (!IS_ERR_OR_NULL(c->gc_thread)) kthread_stop(c->gc_thread); - if (!IS_ERR(c->root)) + if (!IS_ERR_OR_NULL(c->root)) list_add(&c->root->list, &c->btree_cache); /* -- 2.47.1

11 months, 1 week

2
2
0 0

[PATCH] clk: en7523: Fix wrong BUS clock for EN7581

by Christian Marangi

The Documentation for EN7581 had a typo and still referenced the EN7523 BUS base source frequency. This was in conflict with a different page in the Documentration that state that the BUS runs at 300MHz (600MHz source with divisor set to 2) and the actual watchdog that tick at half the BUS clock (150MHz). This was verified with the watchdog by timing the seconds that the system takes to reboot (due too watchdog) and by operating on different values of the BUS divisor. The correct values for source of BUS clock are 600MHz and 540MHz. This was also confirmed by Airoha. Cc: stable(a)vger.kernel.org Fixes: 66bc47326ce2 ("clk: en7523: Add EN7581 support") Signed-off-by: Christian Marangi <ansuelsmth(a)gmail.com> --- drivers/clk/clk-en7523.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/clk/clk-en7523.c b/drivers/clk/clk-en7523.c index e52c5460e927..239cb04d9ae3 100644 --- a/drivers/clk/clk-en7523.c +++ b/drivers/clk/clk-en7523.c @@ -87,6 +87,7 @@ static const u32 slic_base[] = { 100000000, 3125000 }; static const u32 npu_base[] = { 333000000, 400000000, 500000000 }; /* EN7581 */ static const u32 emi7581_base[] = { 540000000, 480000000, 400000000, 300000000 }; +static const u32 bus7581_base[] = { 600000000, 540000000 }; static const u32 npu7581_base[] = { 800000000, 750000000, 720000000, 600000000 }; static const u32 crypto_base[] = { 540000000, 480000000 }; @@ -222,8 +223,8 @@ static const struct en_clk_desc en7581_base_clks[] = { .base_reg = REG_BUS_CLK_DIV_SEL, .base_bits = 1, .base_shift = 8, - .base_values = bus_base, - .n_base_values = ARRAY_SIZE(bus_base), + .base_values = bus7581_base, + .n_base_values = ARRAY_SIZE(bus7581_base), .div_bits = 3, .div_shift = 0, -- 2.45.2

11 months, 1 week

3
2
0 0

Re: [PATCH 6.12 000/826] 6.12.2-rc1 review

by Ronald Warsow

Hi Greg no regressions here on x86_64 (RKL, Intel 11th Gen. CPU) Thanks Tested-by: Ronald Warsow <rwarsow(a)gmx.de>

11 months, 1 week

1
0
0 0

[PATCH v5 0/5] media: uvcvideo: Two +1 fixes for async controls

by Ricardo Ribalda

This patchset fixes two +1 bugs with the async controls for the uvc driver. They were found while implementing the granular PM, but I am sending them as a separate patches, so they can be reviewed sooner. They fix real issues in the driver that need to be taken care. Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- Changes in v5: - Move set handle to the entity_commit - Replace uvc_ctrl_set_handle with get/put_handle. - Add a patch to flush the cache of async controls. - Link to v4: https://lore.kernel.org/r/20241129-uvc-fix-async-v4-0-f23784dba80f@chromium… Changes in v4: - Fix implementation of uvc_ctrl_set_handle. - Link to v3: https://lore.kernel.org/r/20241129-uvc-fix-async-v3-0-ab675ce66db7@chromium… Changes in v3: - change again! order of patches. - Introduce uvc_ctrl_set_handle. - Do not change ctrl->handle if it is not NULL. Changes in v2: - Annotate lockdep - ctrl->handle != handle - Change order of patches - Move documentation of mutex - Link to v1: https://lore.kernel.org/r/20241127-uvc-fix-async-v1-0-eb8722531b8c@chromium… --- Ricardo Ribalda (5): media: uvcvideo: Only save async fh if success media: uvcvideo: Remove dangling pointers media: uvcvideo: Annotate lock requirements for uvc_ctrl_set media: uvcvideo: Remove redundant NULL assignment media: uvcvideo: Flush the control cache when we get an event drivers/media/usb/uvc/uvc_ctrl.c | 77 ++++++++++++++++++++++++++++++++++------ drivers/media/usb/uvc/uvc_v4l2.c | 2 ++ drivers/media/usb/uvc/uvcvideo.h | 9 ++++- 3 files changed, 76 insertions(+), 12 deletions(-) --- base-commit: 40384c840ea1944d7c5a392e8975ed088ecf0b37 change-id: 20241127-uvc-fix-async-2c9d40413ad8 Best regards, -- Ricardo Ribalda <ribalda(a)chromium.org>

11 months, 1 week

3
9
0 0

[PATCH] tracing: Fix cmp_entries_dup() to respect sort() comparison rules

by Kuan-Wei Chiu

The cmp_entries_dup() function used as the comparator for sort() violated the symmetry and transitivity properties required by the sorting algorithm. Specifically, it returned 1 whenever memcmp() was non-zero, which broke the following expectations: * Symmetry: If x < y, then y > x. * Transitivity: If x < y and y < z, then x < z. These violations could lead to incorrect sorting and failure to correctly identify duplicate elements. Fix the issue by directly returning the result of memcmp(), which adheres to the required comparison properties. Fixes: 08d43a5fa063 ("tracing: Add lock-free tracing_map") Cc: stable(a)vger.kernel.org Signed-off-by: Kuan-Wei Chiu <visitorckw(a)gmail.com> --- kernel/trace/tracing_map.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/kernel/trace/tracing_map.c b/kernel/trace/tracing_map.c index 3a56e7c8aa4f..1921ade45be3 100644 --- a/kernel/trace/tracing_map.c +++ b/kernel/trace/tracing_map.c @@ -845,15 +845,11 @@ int tracing_map_init(struct tracing_map *map) static int cmp_entries_dup(const void *A, const void *B) { const struct tracing_map_sort_entry *a, *b; - int ret = 0; a = *(const struct tracing_map_sort_entry **)A; b = *(const struct tracing_map_sort_entry **)B; - if (memcmp(a->key, b->key, a->elt->map->key_size)) - ret = 1; - - return ret; + return memcmp(a->key, b->key, a->elt->map->key_size); } static int cmp_entries_sum(const void *A, const void *B) -- 2.34.1

11 months, 1 week

1
0
0 0

[PATCH 6.6] crypto: starfive - Do not free stack buffer

by bin.lan.cn＠eng.windriver.com

From: Jia Jie Ho <jiajie.ho(a)starfivetech.com> [ Upstream commit d7f01649f4eaf1878472d3d3f480ae1e50d98f6c ] RSA text data uses variable length buffer allocated in software stack. Calling kfree on it causes undefined behaviour in subsequent operations. Cc: <stable(a)vger.kernel.org> #6.7+ Signed-off-by: Jia Jie Ho <jiajie.ho(a)starfivetech.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Bin Lan <bin.lan.cn(a)windriver.com> --- drivers/crypto/starfive/jh7110-rsa.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/crypto/starfive/jh7110-rsa.c b/drivers/crypto/starfive/jh7110-rsa.c index 1db9a3d02848..3116828d60a0 100644 --- a/drivers/crypto/starfive/jh7110-rsa.c +++ b/drivers/crypto/starfive/jh7110-rsa.c @@ -303,7 +303,6 @@ static int starfive_rsa_enc_core(struct starfive_cryp_ctx *ctx, int enc) err_rsa_crypt: writel(STARFIVE_RSA_RESET, cryp->base + STARFIVE_PKA_CACR_OFFSET); - kfree(rctx->rsa_data); return ret; } -- 2.34.1

11 months, 1 week

4
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024