- Kernel - mailweb.openeuler.org

[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

[PATCH OLK-6.6] smb: client: fix change notify replay double-free
by Lai Zewei 29 Jul '26

29 Jul '26

mainline inclusion from mainline-v7.2-rc1 commit 145f820dcbb2cced374f2532f8a61a44dce4a615 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9675 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_notify_init() fails before the next send, cleanup retains the previous buffer type and frees that response again. Reset response bookkeeping before each attempt to prevent the stale free. Fixes: 4f1fffa23769 ("cifs: commands that are retried should have replay flag set") Cc: stable(a)vger.kernel.org Signed-off-by: Henrique Carvalho <henrique.carvalho(a)suse.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/smb/client/smb2pdu.c [ctx conflicts] Signed-off-by: Lai Zewei <laizewei3(a)huawei.com> --- fs/smb/client/smb2pdu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c index 6c12f696122f..367c414195d4 100644 --- a/fs/smb/client/smb2pdu.c +++ b/fs/smb/client/smb2pdu.c @@ -4021,6 +4021,8 @@ SMB2_change_notify(const unsigned int xid, struct cifs_tcon *tcon, replay_again: /* reinitialize for possible replay */ + resp_buftype = CIFS_NO_BUFFER; + memset(&rsp_iov, 0, sizeof(rsp_iov)); flags = 0; server = cifs_pick_channel(ses); -- 2.52.0

2 13

[PATCH OLK-6.6 0/2] Fix CVE-2026-64448
by Zizhi Wo 28 Jul '26

28 Jul '26

Fix CVE-2026-64448 Shoichiro Miyamoto (2): smb: client: restrict implied bcc[0] exemption to responses without data area smb: client: reject overlapping data areas in SMB2 responses fs/smb/client/smb2misc.c | 52 +++++++++++++++++++++++++++++++++------- 1 file changed, 44 insertions(+), 8 deletions(-) -- 2.52.0

2 3

[PATCH OLK-6.6 V2 0/4] Fix CVE-2026-64378
by Zizhi Wo 28 Jul '26

28 Jul '26

Fix CVE-2026-64378 Baokun Li (2): writeback: fix race between cgroup_writeback_umount() and inode_switch_wbs() writeback: drop now-unnecessary rcu_barrier() in cgroup_writeback_umount() Jan Kara (2): writeback: Avoid contention on wb->list_lock when switching inodes writeback: Fix use after free in inode_switch_wbs_work_fn() fs/fs-writeback.c | 134 +++++++++++++++++++++---------- include/linux/backing-dev-defs.h | 15 +++- include/linux/writeback.h | 2 + mm/backing-dev.c | 25 ++++++ 4 files changed, 134 insertions(+), 42 deletions(-) -- 2.52.0

2 5