- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level
by Zhang Kunbo 29 Jul '26

29 Jul '26

From: Sean Christopherson <seanjc(a)google.com> stable inclusion from stable-v6.6.144 commit 48b91ed7e22bb82571c34f8b80b6ecdc90a6fab8 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16138 CVE: CVE-2026-63807 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit ef057cbf825e03b63f6edf5980f96abf3c53089d upstream. When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, *before* querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpage_info (which typically manifests as a host #PF because the lpage_info is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends "below" the bounds of a memslot. When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a "direct" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage. But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds. BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmu_stress_test Not tainted 7.1.0-rc1-48ce1e26eace-x86_pir_to_irr_comments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_mmu_max_mapping_level+0x79/0x2b0 [kvm] Call Trace: <TASK> kvm_mmu_recover_huge_pages+0x21b/0x320 [kvm] kvm_set_memslot+0x1ee/0x590 [kvm] kvm_set_memory_region.part.0+0x3a1/0x4d0 [kvm] kvm_vm_ioctl+0x9bf/0x15d0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0xb7/0xbb0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf </TASK> Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVM_PAGES_PER_HPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvm_mmu_max_mapping_level() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization. Fixes: 9eba50f8d7fc ("KVM: x86/mmu: Consult max mapping level when zapping collapsible SPTEs") Cc: stable(a)vger.kernel.org Cc: David Matlack <dmatlack(a)google.com> Cc: James Houghton <jthoughton(a)google.com> Cc: Alexander Bulekov <bkov(a)amazon.com> Cc: Fred Griffoul <fgriffo(a)amazon.co.uk> Cc: Alexander Graf <graf(a)amazon.de> Cc: David Woodhouse <dwmw(a)amazon.co.uk> Cc: Filippo Sironi <sironi(a)amazon.de> Cc: Ivan Orlov <iorlov(a)amazon.co.uk> Signed-off-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> conflicts: include/linux/kvm_host.h [context conflicts] Signed-off-by: Zhang Kunbo <zhangkunbo(a)huawei.com> --- arch/x86/kvm/mmu/mmu.c | 18 ++++++++++++------ include/linux/kvm_host.h | 7 ++++++- 2 files changed, 18 insertions(+), 7 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 6ee54414295b..2d71bcd36eca 100755 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -6466,13 +6466,19 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm, sp = sptep_to_sp(sptep); /* - * We cannot do huge page mapping for indirect shadow pages, - * which are found on the last rmap (level = 1) when not using - * tdp; such shadow pages are synced with the page table in - * the guest, and the guest page table is using 4K page size - * mapping if the indirect sp has level = 1. + * Direct shadow page can be replaced by a hugepage if the host + * mapping level allows it and the memslot maps all of the host + * hugepage. Note! If the memslot maps only part of the + * hugepage, sp->gfn may be below slot->base_gfn, and querying + * the max mapping level would cause an out-of-bounds lpage_info + * access. So the gfn bounds check *must* be done first. + * + * Indirect shadow pages are created when the guest page tables + * are using 4K pages. Since the host mapping is always + * constrained by the page size in the guest, indirect shadow + * pages are never collapsible. */ - if (sp->role.direct && + if (sp->role.direct && is_gfn_in_memslot(slot, sp->gfn) && sp->role.level < kvm_mmu_max_mapping_level(kvm, slot, sp->gfn, PG_LEVEL_NUM)) { kvm_zap_one_rmap_spte(kvm, rmap_head, sptep); diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 3bf870ffc8b7..783be5bb05c8 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -1184,6 +1184,11 @@ int kvm_request_irq_source_id(struct kvm *kvm); void kvm_free_irq_source_id(struct kvm *kvm, int irq_source_id); bool kvm_arch_irqfd_allowed(struct kvm *kvm, struct kvm_irqfd *args); +static inline bool is_gfn_in_memslot(const struct kvm_memory_slot *slot, gfn_t gfn) +{ + return gfn >= slot->base_gfn && gfn < slot->base_gfn + slot->npages; +} + void kire_arch_cached_data_update(struct kvm *kvm, struct kvm_kernel_irq_routing_entry *e); /* @@ -1206,7 +1211,7 @@ try_get_memslot(struct kvm_memslots *slots, int slot_index, gfn_t gfn) slot_index = array_index_nospec(slot_index, slots->used_slots); slot = &slots->memslots[slot_index]; - if (gfn >= slot->base_gfn && gfn < slot->base_gfn + slot->npages) + if (is_gfn_in_memslot(slot, gfn)) return slot; else return NULL; -- 2.34.1

2 1

[PATCH OLK-6.6] drivers/base/memory: fix memory block reference leak in poison accounting
by Lin Ruifeng 29 Jul '26

29 Jul '26

From: Muchun Song <songmuchun(a)bytedance.com> stable inclusion from stable-v6.6.142 commit 686b4283f82cd630fafd7ca9b03dfc080b3ec8fa category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16374 CVE: CVE-2026-64182 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 03a2cc1756a0570f887d624cd6c535ea0cbd4951 upstream. memblk_nr_poison_inc() and memblk_nr_poison_sub() look up a memory block via find_memory_block_by_id(), which acquires a reference to the memory block device. Both helpers use the returned memory block without dropping that reference, leaking the device reference on each successful lookup. Drop the reference after updating nr_hwpoison. Link: https://lore.kernel.org/20260428085219.1316047-3-songmuchun@bytedance.com Fixes: 5033091de814 ("mm/hwpoison: introduce per-memory_block hwpoison counter") Signed-off-by: Muchun Song <songmuchun(a)bytedance.com> Reviewed-by: Miaohe Lin <linmiaohe(a)huawei.com> Acked-by: Oscar Salvador <osalvador(a)suse.de> Acked-by: David Hildenbrand (Arm) <david(a)kernel.org> Cc: Danilo Krummrich <dakr(a)kernel.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: "Huang, Ying" <huang.ying.caritas(a)gmail.com> Cc: Naoya Horiguchi <nao.horiguchi(a)gmail.com> Cc: "Rafael J. Wysocki" <rafael(a)kernel.org> Cc: Vishal Verma <vishal.l.verma(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/base/memory.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/base/memory.c b/drivers/base/memory.c index 32a7bbc00599..2196b53a62f7 100644 --- a/drivers/base/memory.c +++ b/drivers/base/memory.c @@ -1306,8 +1306,10 @@ void memblk_nr_poison_inc(unsigned long pfn) const unsigned long block_id = pfn_to_block_id(pfn); struct memory_block *mem = find_memory_block_by_id(block_id); - if (mem) + if (mem) { atomic_long_inc(&mem->nr_hwpoison); + put_device(&mem->dev); + } } void memblk_nr_poison_sub(unsigned long pfn, long i) @@ -1315,8 +1317,10 @@ void memblk_nr_poison_sub(unsigned long pfn, long i) const unsigned long block_id = pfn_to_block_id(pfn); struct memory_block *mem = find_memory_block_by_id(block_id); - if (mem) + if (mem) { atomic_long_sub(i, &mem->nr_hwpoison); + put_device(&mem->dev); + } } static unsigned long memblk_nr_poison(struct memory_block *mem) -- 2.34.1

2 1

[PATCH OLK-6.6] spi: qup: fix error pointer deref after DMA setup failure
by Lin Ruifeng 29 Jul '26

29 Jul '26

From: Johan Hovold <johan(a)kernel.org> stable inclusion from stable-v6.6.142 commit 45760b72e84c1a1498f1a8a9047184c85299da20 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16365 CVE: CVE-2026-64170 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a7e8f3efd50a165ba0189f6dc57f7e51a7d149db ] The driver falls back to PIO mode if DMA setup fails during probe. Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer (or attempting to release a channel a second time) on later probe errors or driver unbind. This issue was flagged by Sashiko when reviewing a devres allocation conversion patch. Fixes: 612762e82ae6 ("spi: qup: Add DMA capabilities") Link: https://sashiko.dev/#/patchset/20260505072909.618363-1-johan%40kernel.org?p… Cc: stable(a)vger.kernel.org # 4.1 Signed-off-by: Johan Hovold <johan(a)kernel.org> Link: https://patch.msgid.link/20260512074334.914735-1-johan@kernel.org Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/spi/spi-qup.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c index 1e9cd86d9dcc..fd442062847d 100644 --- a/drivers/spi/spi-qup.c +++ b/drivers/spi/spi-qup.c @@ -967,8 +967,11 @@ static int spi_qup_init_dma(struct spi_controller *host, resource_size_t base) err: dma_release_channel(host->dma_tx); + host->dma_tx = NULL; err_tx: dma_release_channel(host->dma_rx); + host->dma_rx = NULL; + return ret; } -- 2.34.1

2 1

[PATCH OLK-6.6] i2c: stub: Reject I2C block transfers with invalid length
by Lin Ruifeng 29 Jul '26

29 Jul '26

From: Weiming Shi <bestswngs(a)gmail.com> stable inclusion from stable-v6.6.144 commit 1c4ffe6b4f04365485ed58d64c9bb86b46fc9037 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16516 CVE: CVE-2026-64191 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 6036b5067a8199ba7a2dc7b377d4b9dd276d5f9e upstream. The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: <TASK> stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK> The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated(). Fixes: 4710317891e4 ("i2c-stub: Implement I2C block support") Reported-by: Xiang Mei <xmei5(a)asu.edu> Signed-off-by: Weiming Shi <bestswngs(a)gmail.com> Reviewed-by: Jean Delvare <jdelvare(a)suse.de> Signed-off-by: Wolfram Sang <wsa+renesas(a)sang-engineering.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/i2c/i2c-stub.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/i2c/i2c-stub.c b/drivers/i2c/i2c-stub.c index d642cad219d9..3a2f472dd6b0 100644 --- a/drivers/i2c/i2c-stub.c +++ b/drivers/i2c/i2c-stub.c @@ -214,6 +214,11 @@ static s32 stub_xfer(struct i2c_adapter *adap, u16 addr, unsigned short flags, * We ignore banks here, because banked chips don't use I2C * block transfers */ + if (data->block[0] == 0 || + data->block[0] > I2C_SMBUS_BLOCK_MAX) { + ret = -EINVAL; + break; + } if (data->block[0] > 256 - command) /* Avoid overrun */ data->block[0] = 256 - command; len = data->block[0]; -- 2.34.1

2 1

[PATCH OLK-5.10] spi: qup: fix error pointer deref after DMA setup failure
by Lin Ruifeng 29 Jul '26

29 Jul '26

From: Johan Hovold <johan(a)kernel.org> stable inclusion from stable-v5.10.259 commit 0bb3bd442f0bdad3932739a61dd6c580c9c1955e category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16365 CVE: CVE-2026-64170 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a7e8f3efd50a165ba0189f6dc57f7e51a7d149db ] The driver falls back to PIO mode if DMA setup fails during probe. Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer (or attempting to release a channel a second time) on later probe errors or driver unbind. This issue was flagged by Sashiko when reviewing a devres allocation conversion patch. Fixes: 612762e82ae6 ("spi: qup: Add DMA capabilities") Link: https://sashiko.dev/#/patchset/20260505072909.618363-1-johan%40kernel.org?p… Cc: stable(a)vger.kernel.org # 4.1 Signed-off-by: Johan Hovold <johan(a)kernel.org> Link: https://patch.msgid.link/20260512074334.914735-1-johan@kernel.org Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Conflicts: drivers/spi/spi-qup.c [Context Conflicts] Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/spi/spi-qup.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/spi/spi-qup.c b/drivers/spi/spi-qup.c index 2cc9bb413c10..5caf347674f0 100644 --- a/drivers/spi/spi-qup.c +++ b/drivers/spi/spi-qup.c @@ -969,8 +969,10 @@ static int spi_qup_init_dma(struct spi_master *master, resource_size_t base) err: dma_release_channel(master->dma_tx); + master->dma_tx = NULL; err_tx: dma_release_channel(master->dma_rx); + master->dma_rx = NULL; return ret; } -- 2.34.1

2 1

[PATCH OLK-5.10] i2c: stub: Reject I2C block transfers with invalid length
by Lin Ruifeng 29 Jul '26

29 Jul '26

From: Weiming Shi <bestswngs(a)gmail.com> stable inclusion from stable-v5.10.260 commit 7e9072dbd5f2f17934751873450d2c22080ead80 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/16516 CVE: CVE-2026-64191 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 6036b5067a8199ba7a2dc7b377d4b9dd276d5f9e upstream. The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter. A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer: BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: <TASK> stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK> The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not. Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated(). Fixes: 4710317891e4 ("i2c-stub: Implement I2C block support") Reported-by: Xiang Mei <xmei5(a)asu.edu> Signed-off-by: Weiming Shi <bestswngs(a)gmail.com> Reviewed-by: Jean Delvare <jdelvare(a)suse.de> Signed-off-by: Wolfram Sang <wsa+renesas(a)sang-engineering.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/i2c/i2c-stub.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/i2c/i2c-stub.c b/drivers/i2c/i2c-stub.c index 537a598e22db..a8f2251327eb 100644 --- a/drivers/i2c/i2c-stub.c +++ b/drivers/i2c/i2c-stub.c @@ -215,6 +215,11 @@ static s32 stub_xfer(struct i2c_adapter *adap, u16 addr, unsigned short flags, * We ignore banks here, because banked chips don't use I2C * block transfers */ + if (data->block[0] == 0 || + data->block[0] > I2C_SMBUS_BLOCK_MAX) { + ret = -EINVAL; + break; + } if (data->block[0] > 256 - command) /* Avoid overrun */ data->block[0] = 256 - command; len = data->block[0]; -- 2.34.1

2 1

[PATCH OLK-6.6] iov_iter: Fix potential underflow in iov_iter_extract_xarray_pages()
by Chen Jinghuang 29 Jul '26

29 Jul '26

From: David Howells <dhowells(a)redhat.com> mainline inclusion from mainline-v7.2-rc2 commit 55f4bb9373ca4a521f3b0119366db92715a39b81 category: bugfix bugzilla: NA Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm… -------------------------------- In iov_iter_extract_xarray_pages(), if no pages are extracted because there's a hole (or something otherwise unextractable) in the xarray, then the calculation of maxsize at the end can go wrong if the starting offset is not zero. Fix this by returning 0 in such a case and freeing the page array if allocated here rather than being passed in. Note that in the near future, ITER_XARRAY should be removed. Fixes: 7d58fe731028 ("iov_iter: Add a function to extract a page list from an iterator") Link: https://sashiko.dev/#/patchset/20260608145432.681865-1-dhowells%40redhat.com Link: https://sashiko.dev/#/patchset/20260616100821.2062304-1-dhowells%40redhat.c… Signed-off-by: David Howells <dhowells(a)redhat.com> Link: https://patch.msgid.link/20260625140640.3116900-6-dhowells@redhat.com Reviewed-by: Christoph Hellwig <hch(a)lst.de> cc: Paulo Alcantara <pc(a)manguebit.org> cc: Matthew Wilcox <willy(a)infradead.org> cc: Christoph Hellwig <hch(a)infradead.org> cc: Jens Axboe <axboe(a)kernel.dk> cc: Mike Marshall <hubcap(a)omnibond.com> cc: netfs(a)lists.linux.dev cc: linux-fsdevel(a)vger.kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner(a)kernel.org> Conflicts: lib/iov_iter.c [a little context conflict] Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- lib/iov_iter.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/lib/iov_iter.c b/lib/iov_iter.c index 0b8fc9831225..a4cc8d68b409 100644 --- a/lib/iov_iter.c +++ b/lib/iov_iter.c @@ -1625,6 +1625,7 @@ static ssize_t iov_iter_extract_xarray_pages(struct iov_iter *i, struct page *page, **p; unsigned int nr = 0, offset; loff_t pos = i->xarray_start + i->iov_offset; + bool will_alloc = !*pages; pgoff_t index = pos >> PAGE_SHIFT; XA_STATE(xas, i->xarray, index); @@ -1653,6 +1654,14 @@ static ssize_t iov_iter_extract_xarray_pages(struct iov_iter *i, } rcu_read_unlock(); + if (!nr) { + if (will_alloc) { + kvfree(*pages); + *pages = NULL; + } + return 0; + } + maxsize = min_t(size_t, nr * PAGE_SIZE - offset, maxsize); iov_iter_advance(i, maxsize); return maxsize; -- 2.34.1

2 1

[PATCH OLK-6.6] e1000e: Fix out-of-bounds MMIO access by validating BAR0 size
by Pu Lehui 29 Jul '26

29 Jul '26

maillist inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9678 Reference: https://lore.kernel.org/all/20260727025645.2600363-1-pulehui@huaweicloud.com -------------------------------- Syzkaller reported a kernel panic caused by an out-of-bounds MMIO access in the e1000e driver. [ 82.868719][ T404] e1000e 0000:00:02.0: The NVM Checksum Is Not Valid [ 82.872328][ T404] Unable to handle kernel paging request at virtual address ffff80008894e090 [ 83.085218][ T404] CPU: 2 UID: 0 PID: 404 Comm: bash Not tainted 7.2.0-rc2-g3f1f75536668 #1 PREEMPTLAZY [ 83.129013][ T404] pc : e1000_get_cfg_done_82571+0x70/0x158 [ 83.140092][ T404] lr : e1000_get_cfg_done_82571+0x68/0x158 [ 83.151196][ T404] sp : ffff80008ac37410 [ 83.158922][ T404] x29: ffff80008ac37410 x28: ffff0000cd6a11b8 x27: ffff0000c58190d0 [ 83.173919][ T404] x26: ffff0000cd6a11b8 x25: ffff0000cd6a0bc0 x24: ffff0000cd6a0000 [ 83.189417][ T404] x23: 0000000000001010 x22: ffff0000cd6a11c0 x21: ffff0000cd6a11b8 [ 83.205195][ T404] x20: 0000000000000064 x19: ffff80008894e090 x18: 0000000000000000 [ 83.220545][ T404] x17: ffff800081c1a3f4 x16: ffff800081c19c10 x15: ffff800081e86510 [ 83.235764][ T404] x14: 0000000000000001 x13: 0000000000000001 x12: ffff60001bc8a8b3 [ 83.251301][ T404] x11: 1fffe0001bc8a8b2 x10: ffff60001bc8a8b2 x9 : ffff800081eae25c [ 83.266705][ T404] x8 : 00009fffe437574e x7 : ffff0000de454593 x6 : 0000000000000001 [ 83.281919][ T404] x5 : ffff0000cf2b9640 x4 : 0000000000000000 x3 : dfff800000000000 [ 83.297317][ T404] x2 : 0000000000000007 x1 : ffff0000cd6a11c0 x0 : 0000000000000000 [ 83.312601][ T404] Call trace: [ 83.318662][ T404] e1000_get_cfg_done_82571+0x70/0x158 (P) [ 83.329748][ T404] e1000e_phy_hw_reset_generic+0x17c/0x1a8 [ 83.341541][ T404] e1000_probe+0xbd8/0x1988 [ 83.350334][ T404] local_pci_probe+0x84/0x130 Repetition steps: 1. Find PCI device which BAR0 size <= 4K. If it's: Device Addr: 0000:00:02.0 BAR0 SIZE: 4K Vendor/Device ID: 0x1af4 0x1004 2. Unbind the above PCI device echo '0000:00:02.0' > /sys/bus/pci/devices/0000:00:02.0/driver/unbind 3. Set the above device to e1000e new_id echo '1af4 1004' > /sys/bus/pci/drivers/e1000e/new_id During e1000_probe(), the driver maps the device's BAR0 memory region. If the device has a 4K BAR0, ioremap() maps only 4K of space. Later in the probe process, when the NVM checksum validation fails, the driver attempts to perform a hardware reset and falls back to the err_eeprom cleanup path. This cleanup path will trigger an OOB access kernel panic: e1000_phy_hw_reset e1000e_phy_hw_reset_generic e1000_get_cfg_done_82571 er32(EEMNGCTL) readl(hw->hw_addr + EEMNGCTL); <-- EEMNGCTL(0x1010) > 4K, OOB access Fix this by verifying that the MMIO length (pci_resource_len(pdev, 0)) is at least SZ_64K before calling ioremap(). This accounts not only for standard registers up to E1000_SYSSTMPH, but also for flash registers mapped on ICH/PCH chipsets (up to offset 0xE074 / ~57.1 KB). Since PCI BAR sizes are power-of-two aligned, SZ_64K is the minimum valid BAR0 size required to ensure all subsequent MMIO accesses remain strictly within the mapped boundary. Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver (currently for ICH9 devices only)") Reviewed-by: Breno Leitao <leitao(a)debian.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- drivers/net/ethernet/intel/e1000e/netdev.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c index 3b1d142ebf27..c638c4b42ee8 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -7435,6 +7435,12 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent) mmio_len = pci_resource_len(pdev, 0); err = -EIO; + /* Smallest BAR0 that covers every register the driver accesses */ + if (mmio_len < SZ_64K) { + dev_err(&pdev->dev, "MMIO len is too small\n"); + goto err_ioremap; + } + adapter->hw.hw_addr = ioremap(mmio_start, mmio_len); if (!adapter->hw.hw_addr) goto err_ioremap; -- 2.34.1

2 1

[PATCH OLK-5.10] e1000e: Fix out-of-bounds MMIO access by validating BAR0 size
by Pu Lehui 29 Jul '26

29 Jul '26

maillist inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9678 Reference: https://lore.kernel.org/all/20260727025645.2600363-1-pulehui@huaweicloud.com -------------------------------- Syzkaller reported a kernel panic caused by an out-of-bounds MMIO access in the e1000e driver. [ 82.868719][ T404] e1000e 0000:00:02.0: The NVM Checksum Is Not Valid [ 82.872328][ T404] Unable to handle kernel paging request at virtual address ffff80008894e090 [ 83.085218][ T404] CPU: 2 UID: 0 PID: 404 Comm: bash Not tainted 7.2.0-rc2-g3f1f75536668 #1 PREEMPTLAZY [ 83.129013][ T404] pc : e1000_get_cfg_done_82571+0x70/0x158 [ 83.140092][ T404] lr : e1000_get_cfg_done_82571+0x68/0x158 [ 83.151196][ T404] sp : ffff80008ac37410 [ 83.158922][ T404] x29: ffff80008ac37410 x28: ffff0000cd6a11b8 x27: ffff0000c58190d0 [ 83.173919][ T404] x26: ffff0000cd6a11b8 x25: ffff0000cd6a0bc0 x24: ffff0000cd6a0000 [ 83.189417][ T404] x23: 0000000000001010 x22: ffff0000cd6a11c0 x21: ffff0000cd6a11b8 [ 83.205195][ T404] x20: 0000000000000064 x19: ffff80008894e090 x18: 0000000000000000 [ 83.220545][ T404] x17: ffff800081c1a3f4 x16: ffff800081c19c10 x15: ffff800081e86510 [ 83.235764][ T404] x14: 0000000000000001 x13: 0000000000000001 x12: ffff60001bc8a8b3 [ 83.251301][ T404] x11: 1fffe0001bc8a8b2 x10: ffff60001bc8a8b2 x9 : ffff800081eae25c [ 83.266705][ T404] x8 : 00009fffe437574e x7 : ffff0000de454593 x6 : 0000000000000001 [ 83.281919][ T404] x5 : ffff0000cf2b9640 x4 : 0000000000000000 x3 : dfff800000000000 [ 83.297317][ T404] x2 : 0000000000000007 x1 : ffff0000cd6a11c0 x0 : 0000000000000000 [ 83.312601][ T404] Call trace: [ 83.318662][ T404] e1000_get_cfg_done_82571+0x70/0x158 (P) [ 83.329748][ T404] e1000e_phy_hw_reset_generic+0x17c/0x1a8 [ 83.341541][ T404] e1000_probe+0xbd8/0x1988 [ 83.350334][ T404] local_pci_probe+0x84/0x130 Repetition steps: 1. Find PCI device which BAR0 size <= 4K. If it's: Device Addr: 0000:00:02.0 BAR0 SIZE: 4K Vendor/Device ID: 0x1af4 0x1004 2. Unbind the above PCI device echo '0000:00:02.0' > /sys/bus/pci/devices/0000:00:02.0/driver/unbind 3. Set the above device to e1000e new_id echo '1af4 1004' > /sys/bus/pci/drivers/e1000e/new_id During e1000_probe(), the driver maps the device's BAR0 memory region. If the device has a 4K BAR0, ioremap() maps only 4K of space. Later in the probe process, when the NVM checksum validation fails, the driver attempts to perform a hardware reset and falls back to the err_eeprom cleanup path. This cleanup path will trigger an OOB access kernel panic: e1000_phy_hw_reset e1000e_phy_hw_reset_generic e1000_get_cfg_done_82571 er32(EEMNGCTL) readl(hw->hw_addr + EEMNGCTL); <-- EEMNGCTL(0x1010) > 4K, OOB access Fix this by verifying that the MMIO length (pci_resource_len(pdev, 0)) is at least SZ_64K before calling ioremap(). This accounts not only for standard registers up to E1000_SYSSTMPH, but also for flash registers mapped on ICH/PCH chipsets (up to offset 0xE074 / ~57.1 KB). Since PCI BAR sizes are power-of-two aligned, SZ_64K is the minimum valid BAR0 size required to ensure all subsequent MMIO accesses remain strictly within the mapped boundary. Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver (currently for ICH9 devices only)") Reviewed-by: Breno Leitao <leitao(a)debian.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- drivers/net/ethernet/intel/e1000e/netdev.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c index 9e383ce1008e..86a88fe8401d 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -7377,6 +7377,12 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent) mmio_len = pci_resource_len(pdev, 0); err = -EIO; + /* Smallest BAR0 that covers every register the driver accesses */ + if (mmio_len < SZ_64K) { + dev_err(&pdev->dev, "MMIO len is too small\n"); + goto err_ioremap; + } + adapter->hw.hw_addr = ioremap(mmio_start, mmio_len); if (!adapter->hw.hw_addr) goto err_ioremap; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] e1000e: Fix out-of-bounds MMIO access by validating BAR0 size
by Pu Lehui 29 Jul '26

29 Jul '26

maillist inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9678 Reference: https://lore.kernel.org/all/20260727025645.2600363-1-pulehui@huaweicloud.com -------------------------------- Syzkaller reported a kernel panic caused by an out-of-bounds MMIO access in the e1000e driver. [ 82.868719][ T404] e1000e 0000:00:02.0: The NVM Checksum Is Not Valid [ 82.872328][ T404] Unable to handle kernel paging request at virtual address ffff80008894e090 [ 83.085218][ T404] CPU: 2 UID: 0 PID: 404 Comm: bash Not tainted 7.2.0-rc2-g3f1f75536668 #1 PREEMPTLAZY [ 83.129013][ T404] pc : e1000_get_cfg_done_82571+0x70/0x158 [ 83.140092][ T404] lr : e1000_get_cfg_done_82571+0x68/0x158 [ 83.151196][ T404] sp : ffff80008ac37410 [ 83.158922][ T404] x29: ffff80008ac37410 x28: ffff0000cd6a11b8 x27: ffff0000c58190d0 [ 83.173919][ T404] x26: ffff0000cd6a11b8 x25: ffff0000cd6a0bc0 x24: ffff0000cd6a0000 [ 83.189417][ T404] x23: 0000000000001010 x22: ffff0000cd6a11c0 x21: ffff0000cd6a11b8 [ 83.205195][ T404] x20: 0000000000000064 x19: ffff80008894e090 x18: 0000000000000000 [ 83.220545][ T404] x17: ffff800081c1a3f4 x16: ffff800081c19c10 x15: ffff800081e86510 [ 83.235764][ T404] x14: 0000000000000001 x13: 0000000000000001 x12: ffff60001bc8a8b3 [ 83.251301][ T404] x11: 1fffe0001bc8a8b2 x10: ffff60001bc8a8b2 x9 : ffff800081eae25c [ 83.266705][ T404] x8 : 00009fffe437574e x7 : ffff0000de454593 x6 : 0000000000000001 [ 83.281919][ T404] x5 : ffff0000cf2b9640 x4 : 0000000000000000 x3 : dfff800000000000 [ 83.297317][ T404] x2 : 0000000000000007 x1 : ffff0000cd6a11c0 x0 : 0000000000000000 [ 83.312601][ T404] Call trace: [ 83.318662][ T404] e1000_get_cfg_done_82571+0x70/0x158 (P) [ 83.329748][ T404] e1000e_phy_hw_reset_generic+0x17c/0x1a8 [ 83.341541][ T404] e1000_probe+0xbd8/0x1988 [ 83.350334][ T404] local_pci_probe+0x84/0x130 Repetition steps: 1. Find PCI device which BAR0 size <= 4K. If it's: Device Addr: 0000:00:02.0 BAR0 SIZE: 4K Vendor/Device ID: 0x1af4 0x1004 2. Unbind the above PCI device echo '0000:00:02.0' > /sys/bus/pci/devices/0000:00:02.0/driver/unbind 3. Set the above device to e1000e new_id echo '1af4 1004' > /sys/bus/pci/drivers/e1000e/new_id During e1000_probe(), the driver maps the device's BAR0 memory region. If the device has a 4K BAR0, ioremap() maps only 4K of space. Later in the probe process, when the NVM checksum validation fails, the driver attempts to perform a hardware reset and falls back to the err_eeprom cleanup path. This cleanup path will trigger an OOB access kernel panic: e1000_phy_hw_reset e1000e_phy_hw_reset_generic e1000_get_cfg_done_82571 er32(EEMNGCTL) readl(hw->hw_addr + EEMNGCTL); <-- EEMNGCTL(0x1010) > 4K, OOB access Fix this by verifying that the MMIO length (pci_resource_len(pdev, 0)) is at least SZ_64K before calling ioremap(). This accounts not only for standard registers up to E1000_SYSSTMPH, but also for flash registers mapped on ICH/PCH chipsets (up to offset 0xE074 / ~57.1 KB). Since PCI BAR sizes are power-of-two aligned, SZ_64K is the minimum valid BAR0 size required to ensure all subsequent MMIO accesses remain strictly within the mapped boundary. Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver (currently for ICH9 devices only)") Reviewed-by: Breno Leitao <leitao(a)debian.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- drivers/net/ethernet/intel/e1000e/netdev.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c index 7583f893ef6e..4801b7dcdfee 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -7112,6 +7112,12 @@ static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent) mmio_len = pci_resource_len(pdev, 0); err = -EIO; + /* Smallest BAR0 that covers every register the driver accesses */ + if (mmio_len < SZ_64K) { + dev_err(&pdev->dev, "MMIO len is too small\n"); + goto err_ioremap; + } + adapter->hw.hw_addr = ioremap(mmio_start, mmio_len); if (!adapter->hw.hw_addr) goto err_ioremap; -- 2.34.1

2 1