June 2025 - Linux-stable-mirror

[PATCH] arm64: Add MIDR-based check for FEAT_ECBHB

by Oliver Upton

Prior to commit e8cde32f111f ("arm64/cpufeatures/kvm: Add ARMv8.9 FEAT_ECBHB bits in ID_AA64MMFR1 register") KVM was erroneously masking FEAT_ECBHB from VMs, giving the perception that safe implementations are actually vulnerable to Spectre-BHB. And, after commit e403e8538359 ("arm64: errata: Assume that unknown CPUs _are_ vulnerable to Spectre BHB") guests are enabling the loop mitigation. This broken virtual hardware is going to be around for some time, so do the ugly thing and check for revisions of Neoverse-V2 [1], Cortex-X3 [2], Cortex-A720 [3], and Neoverse-N3 [4] that are documented to have FEAT_ECBHB. Cc: stable(a)vger.kernel.org Link: https://developer.arm.com/documentation/102375/0002 Link: https://developer.arm.com/documentation/101593/0102 Link: https://developer.arm.com/documentation/102530/0002 Link: https://developer.arm.com/documentation/107997/0001 Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> --- I thoroughly hate this but the alternative of nuking these busted VMs isn't exactly popular... arch/arm64/include/asm/cputype.h | 1 + arch/arm64/kernel/proton-pack.c | 16 ++++++++++++++++ 2 files changed, 17 insertions(+) diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h index d1cc0571798b..5c6152e61cad 100644 --- a/arch/arm64/include/asm/cputype.h +++ b/arch/arm64/include/asm/cputype.h @@ -282,6 +282,7 @@ struct midr_range { #define MIDR_REV_RANGE(m, v, r_min, r_max) MIDR_RANGE(m, v, r_min, v, r_max) #define MIDR_REV(m, v, r) MIDR_RANGE(m, v, r, v, r) #define MIDR_ALL_VERSIONS(m) MIDR_RANGE(m, 0, 0, 0xf, 0xf) +#define MIDR_MIN_VERSION(m, v, r) MIDR_RANGE(m, v, r, 0xf, 0xf) static inline bool midr_is_cpu_model_range(u32 midr, u32 model, u32 rv_min, u32 rv_max) diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pack.c index b198dde79e59..3d00d4c22d58 100644 --- a/arch/arm64/kernel/proton-pack.c +++ b/arch/arm64/kernel/proton-pack.c @@ -962,8 +962,24 @@ static bool has_spectre_bhb_fw_mitigation(void) static bool supports_ecbhb(int scope) { + static const struct midr_range spectre_ecbhb_list[] = { + MIDR_MIN_VERSION(MIDR_NEOVERSE_V2, 0, 2), + MIDR_MIN_VERSION(MIDR_CORTEX_X3, 1, 1), + MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N3), + MIDR_MIN_VERSION(MIDR_CORTEX_A720, 0, 1), + {}, + }; u64 mmfr1; + /* + * Prior to commit e8cde32f111f ("arm64/cpufeatures/kvm: Add ARMv8.9 + * FEAT_ECBHB bits in ID_AA64MMFR1 register"), KVM masked FEAT_ECBHB + * on implementations that actually have the feature. That sucks; infer + * presence of FEAT_ECBHB based on MIDR. + */ + if (is_midr_in_range_list(spectre_ecbhb_list)) + return true; + if (scope == SCOPE_LOCAL_CPU) mmfr1 = read_sysreg_s(SYS_ID_AA64MMFR1_EL1); else base-commit: b4432656b36e5cc1d50a1f2dc15357543add530e -- 2.39.5

3 weeks, 6 days

2
2
0 0

[PATCH v3 0/3] pwm: axi-pwmgen: add external clock

by David Lechner

When we created the driver for the AXI PWMGEN IP block, we overlooked the fact that it can optionally be configured to use an external clock in addition to the AXI bus clock. This is easy to miss in testing because the bus clock is always on because it is driving other peripherals as well. Up to now, users were specifying the external clock if there was one and the AXI bus clock otherwise. But the proper way to do this is to would be to always specify the bus clock and only specify the external clock if the IP block has been configured to use it. To fix this, we add clock-names to the devicetree bindings and change clocks to allow 1 or 2 clocks. --- Changes in v3: - Fixed clock-names DT property restrictions (was failing dt_binding_check) - Added Cc: stable - Picked up trailers - Link to v2: https://lore.kernel.org/r/20250522-pwm-axi-pwmgen-add-external-clock-v2-0-0… Changes in v2: - Consider this a fix rather than a new feature. - Make clock-names required. - Simplify the logic in the pwm driver to avoid needing to test if clock-names is present in old dtbs that used the broken binding. - Link to v1: https://lore.kernel.org/r/20250520-pwm-axi-pwmgen-add-external-clock-v1-0-6… --- David Lechner (3): dt-bindings: pwm: adi,axi-pwmgen: update documentation link dt-bindings: pwm: adi,axi-pwmgen: fix clocks pwm: axi-pwmgen: fix missing separate external clock .../devicetree/bindings/pwm/adi,axi-pwmgen.yaml | 15 +++++++++++--- drivers/pwm/pwm-axi-pwmgen.c | 23 +++++++++++++++++++--- 2 files changed, 32 insertions(+), 6 deletions(-) --- base-commit: 484803582c77061b470ac64a634f25f89715be3f change-id: 20250515-pwm-axi-pwmgen-add-external-clock-0364fbdf809b Best regards, -- David Lechner <dlechner(a)baylibre.com>

4 weeks

3
4
0 0

[PATCH 5.4.y 0/1] Manual Backport of 099606a7b2d5 to 5.4

by Harshvardhan Jha

The patch 099606a7b2d5 didn't cleanly apply to 5.4 due to the significant difference in codebases. I've tried to manually bring it back to 5.4 via some minor conflict resolution but also invoking the newly introduced API using inverted logic as the conditionals present in 5.4 are the opposite of those in 6.1 xen/swiotlib. Harshvardhan Jha (1): xen/swiotlb: relax alignment requirements drivers/xen/swiotlb-xen.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) -- 2.47.1

4 weeks

2
2
0 0

[PATCH 5.10.y 0/1] Manual Backport of 099606a7b2d5 to 5.10

by Harshvardhan Jha

The patch 099606a7b2d5 didn't cleanly apply to 5.10 due to the significant difference in codebases. I've tried to manually bring it back to 5.10 via some minor conflict resolution but also invoking the newly introduced API using inverted logic as the conditionals present in 5.10 are the opposite of those in 6.1 xen/swiotlib. Harshvardhan Jha (1): xen/swiotlb: relax alignment requirements drivers/xen/swiotlb-xen.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) -- 2.47.1

4 weeks

2
2
0 0

[PATCH 5.10/5.15] perf/arm-cmn: Initialise cmn->cpu earlier

by Robin Murphy

commit 597704e201068db3d104de3c7a4d447ff8209127 upstream. For all the complexity of handling affinity for CPU hotplug, what we've apparently managed to overlook is that arm_cmn_init_irqs() has in fact always been setting the *initial* affinity of all IRQs to CPU 0, not the CPU we subsequently choose for event scheduling. Oh dear. Cc: stable(a)vger.kernel.org Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver") Signed-off-by: Robin Murphy <robin.murphy(a)arm.com> Reviewed-by: Ilkka Koskinen <ilkka(a)os.amperecomputing.com> Link: https://lore.kernel.org/r/b12fccba6b5b4d2674944f59e4daad91cd63420b.17470699… Signed-off-by: Will Deacon <will(a)kernel.org> [ backport past NUMA changes in 5.17 ] Signed-off-by: Robin Murphy <robin.murphy(a)arm.com> --- drivers/perf/arm-cmn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c index e2a055ba0b7a..cabeff8c944b 100644 --- a/drivers/perf/arm-cmn.c +++ b/drivers/perf/arm-cmn.c @@ -1512,6 +1512,7 @@ static int arm_cmn_probe(struct platform_device *pdev) return -ENOMEM; cmn->dev = &pdev->dev; + cmn->cpu = raw_smp_processor_id(); platform_set_drvdata(pdev, cmn); if (has_acpi_companion(cmn->dev)) @@ -1533,7 +1534,6 @@ static int arm_cmn_probe(struct platform_device *pdev) if (err) return err; - cmn->cpu = raw_smp_processor_id(); cmn->pmu = (struct pmu) { .module = THIS_MODULE, .attr_groups = arm_cmn_attr_groups, -- 2.39.2.101.g768bb238c484.dirty

4 weeks

2
1
0 0

[PATCH 5.10] ibmvnic: Add tx check to prevent skb leak

by Denis Arefev

From: Nick Child <nnac123(a)linux.ibm.com> commit 0983d288caf984de0202c66641577b739caad561 upstream. Below is a summary of how the driver stores a reference to an skb during transmit: tx_buff[free_map[consumer_index]]->skb = new_skb; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index ++; Where variable data looks like this: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] consumer_index^ tx_buff == [skb=null, skb=<ptr>, skb=<ptr>, skb=null, skb=null] The driver has checks to ensure that free_map[consumer_index] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our free_map and tx_buff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT. Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems. Signed-off-by: Nick Child <nnac123(a)linux.ibm.com> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2024-41066 Link: https://nvd.nist.gov/vuln/detail/CVE-2024-41066 --- drivers/net/ethernet/ibm/ibmvnic.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c index 84da6ccaf339..e63220ebb2ea 100644 --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -1625,6 +1625,18 @@ static netdev_tx_t ibmvnic_xmit(struct sk_buff *skb, struct net_device *netdev) (tx_pool->consumer_index + 1) % tx_pool->num_buffers; tx_buff = &tx_pool->tx_buff[index]; + + /* Sanity checks on our free map to make sure it points to an index + * that is not being occupied by another skb. If skb memory is + * not freed then we see congestion control kick in and halt tx. + */ + if (unlikely(tx_buff->skb)) { + dev_warn_ratelimited(dev, "TX free map points to untracked skb (%s %d idx=%d)\n", + skb_is_gso(skb) ? "tso_pool" : "tx_pool", + queue_num, index); + dev_kfree_skb_any(tx_buff->skb); + } + tx_buff->skb = skb; tx_buff->data_dma[0] = data_dma_addr; tx_buff->data_len[0] = skb->len; -- 2.43.0

4 weeks

1
0
0 0

[PATCH] iio: accel: fxls8962af: Fix use after free in fxls8962af_fifo_flush

by Sean Nyekjaer

fxls8962af_fifo_flush() uses indio_dev->active_scan_mask (with iio_for_each_active_channel()) without making sure the indio_dev stays in buffer mode. There is a race if indio_dev exits buffer mode in the middle of the interrupt that flushes the fifo. Fix this by calling iio_device_claim_buffer_mode() to ensure indio_dev can't exit buffer mode during the flush. Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read [...] _find_first_bit_le from fxls8962af_fifo_flush+0x17c/0x290 fxls8962af_fifo_flush from fxls8962af_interrupt+0x80/0x178 fxls8962af_interrupt from irq_thread_fn+0x1c/0x7c irq_thread_fn from irq_thread+0x110/0x1f4 irq_thread from kthread+0xe0/0xfc kthread from ret_from_fork+0x14/0x2c Fixes: 79e3a5bdd9ef ("iio: accel: fxls8962af: add hw buffered sampling") Cc: stable(a)vger.kernel.org Signed-off-by: Sean Nyekjaer <sean(a)geanix.com> --- drivers/iio/accel/fxls8962af-core.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/iio/accel/fxls8962af-core.c b/drivers/iio/accel/fxls8962af-core.c index 6d23da3e7aa22c61f2d9348bb91d70cc5719a732..7db83ebeea823173d79bf8ff484add16f575edfc 100644 --- a/drivers/iio/accel/fxls8962af-core.c +++ b/drivers/iio/accel/fxls8962af-core.c @@ -973,6 +973,9 @@ static int fxls8962af_fifo_flush(struct iio_dev *indio_dev) if (ret) return ret; + if (iio_device_claim_buffer_mode(indio_dev) < 0) + return 0; + /* Demux hw FIFO into kfifo. */ for (i = 0; i < count; i++) { int j, bit; @@ -989,6 +992,8 @@ static int fxls8962af_fifo_flush(struct iio_dev *indio_dev) tstamp += sample_period; } + iio_device_release_buffer_mode(indio_dev); + return count; } --- base-commit: 5c3fcb36c92443a9a037683626a2e43d8825f783 change-id: 20250524-fxlsrace-f4d20e29fb29 Best regards, -- Sean Nyekjaer <sean(a)geanix.com>

4 weeks

4
9
0 0

[PATCH 5.10] xfs: add bounds checking to xlog_recover_process_data

by Denis Arefev

From: lei lu <llfamsec(a)gmail.com> commit fb63435b7c7dc112b1ae1baea5486e0a6e27b196 upstream. There is a lack of verification of the space occupied by fixed members of xlog_op_header in the xlog_recover_process_data. We can create a crafted image to trigger an out of bounds read by following these steps: 1) Mount an image of xfs, and do some file operations to leave records 2) Before umounting, copy the image for subsequent steps to simulate abnormal exit. Because umount will ensure that tail_blk and head_blk are the same, which will result in the inability to enter xlog_recover_process_data 3) Write a tool to parse and modify the copied image in step 2 4) Make the end of the xlog_op_header entries only 1 byte away from xlog_rec_header->h_size 5) xlog_rec_header->h_num_logops++ 6) Modify xlog_rec_header->h_crc Fix: Add a check to make sure there is sufficient space to access fixed members of xlog_op_header. Signed-off-by: lei lu <llfamsec(a)gmail.com> Reviewed-by: Dave Chinner <dchinner(a)redhat.com> Reviewed-by: Darrick J. Wong <djwong(a)kernel.org> Signed-off-by: Chandan Babu R <chandanbabu(a)kernel.org> Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2024-41014 Link: https://nvd.nist.gov/vuln/detail/cve-2024-41014 --- fs/xfs/xfs_log_recover.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c index e61f28ce3e44..eafe76f304ef 100644 --- a/fs/xfs/xfs_log_recover.c +++ b/fs/xfs/xfs_log_recover.c @@ -2419,7 +2419,10 @@ xlog_recover_process_data( ohead = (struct xlog_op_header *)dp; dp += sizeof(*ohead); - ASSERT(dp <= end); + if (dp > end) { + xfs_warn(log->l_mp, "%s: op header overrun", __func__); + return -EFSCORRUPTED; + } /* errors will abort recovery */ error = xlog_recover_process_ophdr(log, rhash, rhead, ohead, -- 2.43.0

4 weeks

1
0
0 0

Please pick 0c8e9c148e29 and da33e87bd2bf for linux-6.15.y

by Robin Murphy

Hi Greg, Sasha, Please could you pick these commits for linux-6.15.y: 0c8e9c148e29 ("iommu: Avoid introducing more races") da33e87bd2bf ("iommu: Handle yet another race around registration") which in hindsight should ideally have been merged as fixes during the cycle, but for various reasons were queued as 6.16 material at the time. Thanks, Robin.

4 weeks

2
1
0 0

Re: [PATCH v5] virtio_blk: Fix disk deletion hang on device surprise removal

by ALOK TIWARI

On 02-06-2025 08:14, Parav Pandit wrote: > When the PCI device is surprise removed, requests may not complete > the device as the VQ is marked as broken. Due to this, the disk > deletion hangs. > > Fix it by aborting the requests when the VQ is broken. > > With this fix now fio completes swiftly. > An alternative of IO timeout has been considered, however > when the driver knows about unresponsive block device, swiftly clearing > them enables users and upper layers to react quickly. > > Verified with multiple device unplug iterations with pending requests in > virtio used ring and some pending with the device. > > Fixes: 43bb40c5b926 ("virtio_pci: Support surprise removal of virtio pci device") > Cc:stable@vger.kernel.org > Reported-by: Li RongQing<lirongqing(a)baidu.com> > Closes:https://urldefense.com/v3/__https://lore.kernel.org/virtualization/ > c45dd68698cd47238c55fb73ca9b4741(a)baidu.com/__;!!ACWV5N9M2RV99hQ! > OKusQ3sGH7nkVTy9MUDtaIS17UDtjabP3Lby9jTBdT3Ur38XLl2_DOFo0eVzx_dNeh16lD3Ss6ItE9eG$ > Reviewed-by: Max Gurtovoy<mgurtovoy(a)nvidia.com> > Reviewed-by: Israel Rukshin<israelr(a)nvidia.com> > Signed-off-by: Parav Pandit<parav(a)nvidia.com> look good to me. Reviewed-by: Alok Tiwari <alok.a.tiwari(a)oracle.com> Thanks, Alok

4 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2025