- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] serial: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failed
by GUO Zihua 27 Feb '24

27 Feb '24

From: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> stable inclusion from stable-v5.10.209 commit bc57f3ef8a9eb0180606696f586a6dcfaa175ed0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93EDC CVE: CVE-2023-52457 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit ad90d0358bd3b4554f243a425168fc7cebe7d04e ] Returning an error code from .remove() makes the driver core emit the little helpful error message: remove callback returned a non-zero value. This will be ignored. and then remove the device anyhow. So all resources that were not freed are leaked in this case. Skipping serial8250_unregister_port() has the potential to keep enough of the UART around to trigger a use-after-free. So replace the error return (and with it the little helpful error message) by a more useful error message and continue to cleanup. Fixes: e3f0c638f428 ("serial: 8250: omap: Fix unpaired pm_runtime_put_sync() in omap8250_remove()") Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Reviewed-by: Tony Lindgren <tony(a)atomide.com> Link: https://lore.kernel.org/r/20231110152927.70601-2-u.kleine-koenig@pengutroni… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/tty/serial/8250/8250_omap.c Signed-off-by: GUO Zihua <guozihua(a)huawei.com> --- drivers/tty/serial/8250/8250_omap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c index e26ac3f42e05..1967bf314e7c 100644 --- a/drivers/tty/serial/8250/8250_omap.c +++ b/drivers/tty/serial/8250/8250_omap.c @@ -1485,7 +1485,7 @@ static int omap8250_remove(struct platform_device *pdev) err = pm_runtime_resume_and_get(&pdev->dev); if (err) - return err; + dev_err(&pdev->dev, "Failed to resume hardware\n"); pm_runtime_dont_use_autosuspend(&pdev->dev); pm_runtime_put_sync(&pdev->dev); -- 2.34.1

2 1

[PATCH OLK-6.6 00/14] LoongArch: fix some known issue and update defconfig
by Hongchen Zhang 27 Feb '24

27 Feb '24

Bibo Mao (1): LoongArch: Implement constant timer shutdown interface Chong Qiao (1): irqchip/loongson-pch-pic: 7a1000 int_clear reg must use 64bit write. Hongchen Zhang (3): LoongArch: fix compile error caused by arch_trigger_cpumask_backtrace usb: xhci: add XHCI_NO_SOFT_RETRY quirk for EJ188 net: stmmac: fix potential double free of dma descriptor resources Huacai Chen (1): drm/radeon: Workaround radeon driver bug for Loongson Jianmin Lv (1): LoongArch: Remove generic irq migration Tianli Xiong (1): irqchip/loongson-liointc: Set different isr for differnt core Yingkun Meng (1): LoongArch: defconfig: Enable a large number of configurations Youling Tang (4): LoongArch: kdump: Add memory reservation for old kernel LoongArch: kexec: Add compatibility with old interfaces LoongArch: Fix kdump failure on v40 interface specification LoongArch: kdump: Add high memory reservation zhangtianyang (1): LoongArch: Adapted SECTION_SIZE_BITS with page size arch/loongarch/Kconfig | 1 - arch/loongarch/configs/loongson3_defconfig | 1577 +++++++++++++++-- arch/loongarch/include/asm/irq.h | 3 +- arch/loongarch/include/asm/sparsemem.h | 2 +- arch/loongarch/kernel/irq.c | 36 + arch/loongarch/kernel/machine_kexec.c | 45 +- arch/loongarch/kernel/process.c | 3 +- arch/loongarch/kernel/setup.c | 94 +- arch/loongarch/kernel/smp.c | 3 +- arch/loongarch/kernel/time.c | 23 +- drivers/gpu/drm/radeon/cik.c | 3 + drivers/gpu/drm/radeon/evergreen.c | 3 + drivers/gpu/drm/radeon/r600.c | 3 + drivers/gpu/drm/radeon/si.c | 3 + drivers/irqchip/irq-loongson-liointc.c | 4 +- drivers/irqchip/irq-loongson-pch-pic.c | 16 +- .../net/ethernet/stmicro/stmmac/stmmac_main.c | 11 + drivers/usb/host/xhci-pci.c | 6 + kernel/irq/Kconfig | 4 +- 19 files changed, 1639 insertions(+), 201 deletions(-) -- 2.33.0

2 15

[PATCH OLK-5.10] tls: fix race between tx work scheduling and socket close
by Zhengchao Shao 27 Feb '24

27 Feb '24

From: Jakub Kicinski <kuba(a)kernel.org> mainline inclusion from mainline-v6.8-rc5 commit e01e3934a1b2d122919f73bc6ddbe1cdafc4bbdb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I92REM CVE: CVE-2024-26585 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling complete(). This seems more logical in the first place, as it's the inverse order of what the submitting thread will do. Reported-by: valis <sec(a)valis.email> Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption of records for performance") Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Reviewed-by: Simon Horman <horms(a)kernel.org> Reviewed-by: Sabrina Dubroca <sd(a)queasysnail.net> Signed-off-by: David S. Miller <davem(a)davemloft.net> Conflicts: net/tls/tls_sw.c Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- net/tls/tls_sw.c | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index 84e1f2af1a83..e2f4cc5c85bb 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -443,7 +443,6 @@ static void tls_encrypt_done(struct crypto_async_request *req, int err) struct scatterlist *sge; struct sk_msg *msg_en; struct tls_rec *rec; - bool ready = false; int pending; rec = container_of(aead_req, struct tls_rec, aead_req); @@ -475,8 +474,12 @@ static void tls_encrypt_done(struct crypto_async_request *req, int err) /* If received record is at head of tx_list, schedule tx */ first_rec = list_first_entry(&ctx->tx_list, struct tls_rec, list); - if (rec == first_rec) - ready = true; + if (rec == first_rec) { + /* Schedule the transmission */ + if (!test_and_set_bit(BIT_TX_SCHEDULED, + &ctx->tx_bitmask)) + schedule_delayed_work(&ctx->tx_work.work, 1); + } } spin_lock_bh(&ctx->encrypt_compl_lock); @@ -485,13 +488,6 @@ static void tls_encrypt_done(struct crypto_async_request *req, int err) if (!pending && ctx->async_notify) complete(&ctx->async_wait.completion); spin_unlock_bh(&ctx->encrypt_compl_lock); - - if (!ready) - return; - - /* Schedule the transmission */ - if (!test_and_set_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask)) - schedule_delayed_work(&ctx->tx_work.work, 1); } static int tls_do_encryption(struct sock *sk, -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS V2 0/2] Remove WQ_FLAG_BOOKMARK flag
by Zizhi Wo 26 Feb '24

26 Feb '24

Fix softlockup by removing the wait_queue flag: WQ_FLAG_BOOKMARK. Matthew Wilcox (Oracle) (2): filemap: remove use of wait bookmarks sched: remove wait bookmarks include/linux/wait.h | 3 --- kernel/sched/wait.c | 57 ++++++-------------------------------------- mm/filemap.c | 21 +--------------- 3 files changed, 8 insertions(+), 73 deletions(-) -- 2.39.2

2 3

[PATCH OLK-6.6 0/4] kabi: reserve space for arch related
by Liao Chen 26 Feb '24

26 Feb '24

kabi: reserve space for struct irq_work kabi: reserve space for struct irq_domain kabi: reserve space for enum irq_domain_bus_token kabi: reserve space for struct mfd_cell Liao Chen (4): kabi: reserve space for struct irq_work kabi: reserve space for struct irq_domain kabi: reserve space for enum irq_domain_bus_token kabi: reserve space for struct mfd_cell include/linux/irq_work.h | 5 +++++ include/linux/irqdomain.h | 4 ++++ include/linux/irqdomain_defs.h | 8 ++++++++ include/linux/mfd/core.h | 6 ++++++ 4 files changed, 23 insertions(+) -- 2.34.1

2 5

[PATCH OLK-6.6 0/5] Support PV sched feature
by lishusen 26 Feb '24

26 Feb '24

PV sched supports the vCPU preemption check to enhance lock performance on overcommitted hosts Zengruan Ye (5): KVM: arm64: Document PV-sched interface KVM: arm64: Implement PV_SCHED_FEATURES call KVM: arm64: Support pvsched preempted via shared structure KVM: arm64: Add interface to support vCPU preempted check KVM: arm64: Support the vCPU preemption check Documentation/virt/kvm/arm/pvsched.rst | 58 ++++++++++++++ arch/arm64/Kconfig | 11 +++ arch/arm64/configs/openeuler_defconfig | 1 + arch/arm64/include/asm/kvm_host.h | 32 ++++++++ arch/arm64/include/asm/paravirt.h | 11 +++ arch/arm64/include/asm/pvsched-abi.h | 16 ++++ arch/arm64/include/asm/spinlock.h | 8 ++ arch/arm64/kernel/Makefile | 2 +- arch/arm64/kernel/paravirt-spinlocks.c | 16 ++++ arch/arm64/kernel/paravirt.c | 107 +++++++++++++++++++++++++ arch/arm64/kvm/Makefile | 2 +- arch/arm64/kvm/arm.c | 11 +++ arch/arm64/kvm/hypercalls.c | 17 ++++ arch/arm64/kvm/pvsched.c | 54 +++++++++++++ include/linux/arm-smccc.h | 19 +++++ include/linux/cpuhotplug.h | 1 + 16 files changed, 364 insertions(+), 2 deletions(-) create mode 100644 Documentation/virt/kvm/arm/pvsched.rst create mode 100644 arch/arm64/include/asm/pvsched-abi.h create mode 100644 arch/arm64/kernel/paravirt-spinlocks.c create mode 100644 arch/arm64/kvm/pvsched.c -- 2.33.0

2 6

[PATCH OLK-5.10] iomap: add support to track dirty state of sub pages
by Yu Kuai 26 Feb '24

26 Feb '24

hulk inclusion category: performance bugzilla: https://gitee.com/openeuler/kernel/issues/I93TU0 CVE: NA ------------------------------------------ commit 9dc55f1389f9 ("iomap: add support for sub-pagesize buffered I/O without buffer heads") replace the per-block structure buffer_head with the per-page structure iomap_page. However, iomap_page can't track the dirty state of sub pages, which will cause performance issue since sub pages will be writeback even if they are not dirty. For example, if block size is 4k and page size is 64k: dd if=/dev/zero of=testfile bs=4k count=16 oflag=sync With buffer_head implementation, the above dd cmd will writeback 4k in each round. However, with iomap_page implementation, the range of writeback in each round is from the start of the page to the end offset we just wrote. Thus add support to track dirty state in iomap_page. test environment: platform: arm64 pagesize: 64k blocksize: 4k test case: dd if=/dev/zero of=/mnt/testfile bs=1M count=128 fio --ioengine=sync --rw=randwrite --iodepth=64 --name=test \ --filename=/mnt/testfile --bs=4k --fsync=1 The test result is: xfs with patch: WRITE: bw=4609KiB/s (4720kB/s) xfs without patch WRITE: bw=2714KiB/s (2780kB/s) ext4: WRITE: bw=3840KiB/s (3932kB/s) Signed-off-by: Yu Kuai <yukuai3(a)huawei.com> --- fs/iomap/buffered-io.c | 85 +++++++++++++++++++++++++++++++++--------- 1 file changed, 68 insertions(+), 17 deletions(-) diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index d9092aa5c3fb..73524df884bb 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -25,13 +25,13 @@ /* * Structure allocated for each page or THP when block size < page size - * to track sub-page uptodate status and I/O completions. + * to track sub-page uptodate and dirty status and I/O completions. */ struct iomap_page { atomic_t read_bytes_pending; atomic_t write_bytes_pending; - spinlock_t uptodate_lock; - unsigned long uptodate[]; + spinlock_t state_lock; + unsigned long state[]; }; static inline struct iomap_page *to_iomap_page(struct page *page) @@ -59,11 +59,13 @@ iomap_page_create(struct inode *inode, struct page *page) if (iop || nr_blocks <= 1) return iop; - iop = kzalloc(struct_size(iop, uptodate, BITS_TO_LONGS(nr_blocks)), + iop = kzalloc(struct_size(iop, state, BITS_TO_LONGS(2 * nr_blocks)), GFP_NOFS | __GFP_NOFAIL); - spin_lock_init(&iop->uptodate_lock); + spin_lock_init(&iop->state_lock); if (PageUptodate(page)) - bitmap_fill(iop->uptodate, nr_blocks); + bitmap_set(iop->state, 0, nr_blocks); + if (PageDirty(page)) + bitmap_set(iop->state, nr_blocks, nr_blocks); attach_page_private(page, iop); return iop; } @@ -78,7 +80,7 @@ iomap_page_release(struct page *page) return; WARN_ON_ONCE(atomic_read(&iop->read_bytes_pending)); WARN_ON_ONCE(atomic_read(&iop->write_bytes_pending)); - WARN_ON_ONCE(bitmap_full(iop->uptodate, nr_blocks) != + WARN_ON_ONCE(bitmap_full(iop->state, nr_blocks) != PageUptodate(page)); kfree(iop); } @@ -109,7 +111,7 @@ iomap_adjust_read_range(struct inode *inode, struct iomap_page *iop, /* move forward for each leading block marked uptodate */ for (i = first; i <= last; i++) { - if (!test_bit(i, iop->uptodate)) + if (!test_bit(i, iop->state)) break; *pos += block_size; poff += block_size; @@ -119,7 +121,7 @@ iomap_adjust_read_range(struct inode *inode, struct iomap_page *iop, /* truncate len if we find any trailing uptodate block(s) */ for ( ; i <= last; i++) { - if (test_bit(i, iop->uptodate)) { + if (test_bit(i, iop->state)) { plen -= (last - i + 1) * block_size; last = i - 1; break; @@ -143,6 +145,53 @@ iomap_adjust_read_range(struct inode *inode, struct iomap_page *iop, *lenp = plen; } +static void +iomap_set_range_dirty(struct page *page, unsigned int off, unsigned int len) +{ + struct inode *inode = page->mapping->host; + unsigned int nr_blocks = i_blocks_per_page(inode, page); + unsigned int first = off >> inode->i_blkbits; + unsigned int last = (off + len - 1) >> inode->i_blkbits; + unsigned long flags; + struct iomap_page *iop; + + if (PageError(page)) + return; + + if (len) + iomap_set_page_dirty(page); + + if (!page_has_private(page)) + return; + + iop = to_iomap_page(page); + spin_lock_irqsave(&iop->state_lock, flags); + bitmap_set(iop->state, first + nr_blocks, last - first + 1); + spin_unlock_irqrestore(&iop->state_lock, flags); +} + +static void +iomap_clear_range_dirty(struct page *page, unsigned int off, unsigned int len) +{ + struct inode *inode = page->mapping->host; + unsigned int nr_blocks = i_blocks_per_page(inode, page); + unsigned int first = off >> inode->i_blkbits; + unsigned int last = (off + len - 1) >> inode->i_blkbits; + unsigned long flags; + struct iomap_page *iop; + + if (PageError(page)) + return; + + if (!page_has_private(page)) + return; + + iop = to_iomap_page(page); + spin_lock_irqsave(&iop->state_lock, flags); + bitmap_clear(iop->state, first + nr_blocks, last - first + 1); + spin_unlock_irqrestore(&iop->state_lock, flags); +} + static void iomap_iop_set_range_uptodate(struct page *page, unsigned off, unsigned len) { @@ -152,11 +201,11 @@ iomap_iop_set_range_uptodate(struct page *page, unsigned off, unsigned len) unsigned last = (off + len - 1) >> inode->i_blkbits; unsigned long flags; - spin_lock_irqsave(&iop->uptodate_lock, flags); - bitmap_set(iop->uptodate, first, last - first + 1); - if (bitmap_full(iop->uptodate, i_blocks_per_page(inode, page))) + spin_lock_irqsave(&iop->state_lock, flags); + bitmap_set(iop->state, first, last - first + 1); + if (bitmap_full(iop->state, i_blocks_per_page(inode, page))) SetPageUptodate(page); - spin_unlock_irqrestore(&iop->uptodate_lock, flags); + spin_unlock_irqrestore(&iop->state_lock, flags); } static void @@ -451,7 +500,7 @@ iomap_is_partially_uptodate(struct page *page, unsigned long from, if (iop) { for (i = first; i <= last; i++) - if (!test_bit(i, iop->uptodate)) + if (!test_bit(i, iop->state)) return 0; return 1; } @@ -708,7 +757,7 @@ static size_t __iomap_write_end(struct inode *inode, loff_t pos, size_t len, if (unlikely(copied < len && !PageUptodate(page))) return 0; iomap_set_range_uptodate(page, offset_in_page(pos), len); - iomap_set_page_dirty(page); + iomap_set_range_dirty(page, offset_in_page(pos), len); return copied; } @@ -1024,7 +1073,7 @@ iomap_page_mkwrite_actor(struct inode *inode, loff_t pos, loff_t length, block_commit_write(page, 0, length); } else { WARN_ON_ONCE(!PageUptodate(page)); - set_page_dirty(page); + iomap_set_range_dirty(page, offset_in_page(pos), length); } return length; @@ -1407,6 +1456,7 @@ iomap_writepage_map(struct iomap_writepage_ctx *wpc, { struct iomap_page *iop = iomap_page_create(inode, page); struct iomap_ioend *ioend, *next; + unsigned int nr_blocks = i_blocks_per_page(inode, page); unsigned len = i_blocksize(inode); u64 file_offset; /* file offset of page */ int error = 0, count = 0, i; @@ -1422,7 +1472,7 @@ iomap_writepage_map(struct iomap_writepage_ctx *wpc, for (i = 0, file_offset = page_offset(page); i < (PAGE_SIZE >> inode->i_blkbits) && file_offset < end_offset; i++, file_offset += len) { - if (iop && !test_bit(i, iop->uptodate)) + if (iop && !test_bit(i + nr_blocks, iop->state)) continue; error = wpc->ops->map_blocks(wpc, inode, file_offset); @@ -1465,6 +1515,7 @@ iomap_writepage_map(struct iomap_writepage_ctx *wpc, } } + iomap_clear_range_dirty(page, 0, PAGE_SIZE); set_page_writeback(page); unlock_page(page); -- 2.39.2

2 1

[PATCH OLK-6.6 0/9] Support PV sched feature
by lishusen 26 Feb '24

26 Feb '24

PV sched supports the vCPU preemption check to enhance lock performance on overcommitted hosts Zengruan Ye (5): KVM: arm64: Document PV-sched interface KVM: arm64: Implement PV_SCHED_FEATURES call KVM: arm64: Support pvsched preempted via shared structure KVM: arm64: Add interface to support vCPU preempted check KVM: arm64: Support the vCPU preemption check Documentation/virt/kvm/arm/pvsched.rst | 58 ++++++++++++++ arch/arm64/Kconfig | 11 +++ arch/arm64/configs/openeuler_defconfig | 1 + arch/arm64/include/asm/kvm_host.h | 32 ++++++++ arch/arm64/include/asm/paravirt.h | 11 +++ arch/arm64/include/asm/pvsched-abi.h | 16 ++++ arch/arm64/include/asm/spinlock.h | 8 ++ arch/arm64/kernel/Makefile | 2 +- arch/arm64/kernel/paravirt-spinlocks.c | 16 ++++ arch/arm64/kernel/paravirt.c | 107 +++++++++++++++++++++++++ arch/arm64/kvm/Makefile | 2 +- arch/arm64/kvm/arm.c | 11 +++ arch/arm64/kvm/hypercalls.c | 17 ++++ arch/arm64/kvm/pvsched.c | 54 +++++++++++++ include/linux/arm-smccc.h | 19 +++++ include/linux/cpuhotplug.h | 1 + 16 files changed, 364 insertions(+), 2 deletions(-) create mode 100644 Documentation/virt/kvm/arm/pvsched.rst create mode 100644 arch/arm64/include/asm/pvsched-abi.h create mode 100644 arch/arm64/kernel/paravirt-spinlocks.c create mode 100644 arch/arm64/kvm/pvsched.c -- 2.33.0

2 6

[PATCH v1 OLK-6.6 0/3] The workqueue created by iscsi can automatically identify the CPU of the soft interrupt currently processed by iscsi, and automatically schedule the workqueue to the corresponding NUMA node.
by jiangdongxu 26 Feb '24

26 Feb '24

From: shaodenghui <shaodenghui(a)huawei.com> When the current downstream FS tests IPSAN, it is found that the performance on ARM is much worse than that on X86, and the test data of IPSAN fluctuates greatly. After analysis, the reason is that when iscsi issues IO, the task is sent to kworker for processing by iscsi_xmitworker. shaodenghui (3): iscsi: add member for NUMA aware order workqueue workqueue: implement NUMA affinity for single thread workqueue iscsi: use dynamic single thread workqueue to improve performance drivers/scsi/iscsi_tcp.c | 9 +++++++++ drivers/scsi/libiscsi.c | 17 ++++++++++++----- include/linux/workqueue.h | 1 + include/scsi/libiscsi.h | 1 + kernel/workqueue.c | 15 ++++++++++----- 5 files changed, 33 insertions(+), 10 deletions(-) -- 2.33.0

2 4

[PATCH v1 OLK-6.6 1/3] iscsi: add member for NUMA aware order workqueue
by jiangdongxu 26 Feb '24

26 Feb '24

From: shaodenghui <shaodenghui(a)huawei.com> euleros inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4IZNO CVE: NA ------------------------------------------------- Add member to struct iscsi_conn. Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Reviewed-By: Xie XiuQi <xiexiuqi(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Signed-off-by: BiaoXiang Ye <yebiaoxiang(a)huawei.com> Reviewed-by: fang yi <eric.fangyi(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Signed-off-by: shaodenghui <shaodenghui(a)huawei.com> --- include/linux/workqueue.h | 1 + include/scsi/libiscsi.h | 1 + 2 files changed, 2 insertions(+) diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h index 961909875..485c0f5b2 100644 --- a/include/linux/workqueue.h +++ b/include/linux/workqueue.h @@ -415,6 +415,7 @@ enum { __WQ_ORDERED = 1 << 17, /* internal: workqueue is ordered */ __WQ_LEGACY = 1 << 18, /* internal: create*_workqueue() */ __WQ_ORDERED_EXPLICIT = 1 << 19, /* internal: alloc_ordered_workqueue() */ + __WQ_DYNAMIC = 1 << 25, /* internal: only support single work order WQ */ WQ_MAX_ACTIVE = 512, /* I like 512, better ideas? */ WQ_UNBOUND_MAX_ACTIVE = WQ_MAX_ACTIVE, diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h index d253b82e9..ead17d222 100644 --- a/include/scsi/libiscsi.h +++ b/include/scsi/libiscsi.h @@ -266,6 +266,7 @@ struct iscsi_conn { /* custom statistics */ uint32_t eh_abort_cnt; uint32_t fmr_unalign_cnt; + int intimate_cpu; KABI_RESERVE(1) KABI_RESERVE(2) -- 2.33.0

2 4

[PATCH openEuler-22.03-LTS-SP2] gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump
by Baokun Li 26 Feb '24

26 Feb '24

From: Osama Muhammad <osmtendev(a)gmail.com> stable inclusion from stable-v5.10.209 commit 5c28478af371a1c3fdb570ca67f110e1ae60fc37 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I93ODT CVE: CVE-2023-52448 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8877243beafa7c6bfc42022cbfdf9e39b25bd4fa ] Syzkaller has reported a NULL pointer dereference when accessing rgd->rd_rgl in gfs2_rgrp_dump(). This can happen when creating rgd->rd_gl fails in read_rindex_entry(). Add a NULL pointer check in gfs2_rgrp_dump() to prevent that. Reported-and-tested-by: syzbot+da0fc229cc1ff4bb2e6d(a)syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=da0fc229cc1ff4bb2e6d Fixes: 72244b6bc752 ("gfs2: improve debug information when lvb mismatches are found") Signed-off-by: Osama Muhammad <osmtendev(a)gmail.com> Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/gfs2/rgrp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c index c5bde789a16d..4e760a3fb661 100644 --- a/fs/gfs2/rgrp.c +++ b/fs/gfs2/rgrp.c @@ -2231,7 +2231,7 @@ void gfs2_rgrp_dump(struct seq_file *seq, struct gfs2_rgrpd *rgd, (unsigned long long)rgd->rd_addr, rgd->rd_flags, rgd->rd_free, rgd->rd_free_clone, rgd->rd_dinodes, rgd->rd_reserved, rgd->rd_extfail_pt); - if (rgd->rd_sbd->sd_args.ar_rgrplvb) { + if (rgd->rd_sbd->sd_args.ar_rgrplvb && rgd->rd_rgl) { struct gfs2_rgrp_lvb *rgl = rgd->rd_rgl; gfs2_print_dbg(seq, "%s L: f:%02x b:%u i:%u\n", fs_id_buf, -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS-SP1] gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump
by Baokun Li 26 Feb '24

26 Feb '24

From: Osama Muhammad <osmtendev(a)gmail.com> stable inclusion from stable-v5.10.209 commit 5c28478af371a1c3fdb570ca67f110e1ae60fc37 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I93ODT CVE: CVE-2023-52448 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8877243beafa7c6bfc42022cbfdf9e39b25bd4fa ] Syzkaller has reported a NULL pointer dereference when accessing rgd->rd_rgl in gfs2_rgrp_dump(). This can happen when creating rgd->rd_gl fails in read_rindex_entry(). Add a NULL pointer check in gfs2_rgrp_dump() to prevent that. Reported-and-tested-by: syzbot+da0fc229cc1ff4bb2e6d(a)syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=da0fc229cc1ff4bb2e6d Fixes: 72244b6bc752 ("gfs2: improve debug information when lvb mismatches are found") Signed-off-by: Osama Muhammad <osmtendev(a)gmail.com> Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/gfs2/rgrp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c index c5bde789a16d..4e760a3fb661 100644 --- a/fs/gfs2/rgrp.c +++ b/fs/gfs2/rgrp.c @@ -2231,7 +2231,7 @@ void gfs2_rgrp_dump(struct seq_file *seq, struct gfs2_rgrpd *rgd, (unsigned long long)rgd->rd_addr, rgd->rd_flags, rgd->rd_free, rgd->rd_free_clone, rgd->rd_dinodes, rgd->rd_reserved, rgd->rd_extfail_pt); - if (rgd->rd_sbd->sd_args.ar_rgrplvb) { + if (rgd->rd_sbd->sd_args.ar_rgrplvb && rgd->rd_rgl) { struct gfs2_rgrp_lvb *rgl = rgd->rd_rgl; gfs2_print_dbg(seq, "%s L: f:%02x b:%u i:%u\n", fs_id_buf, -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS] gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump
by Baokun Li 26 Feb '24

26 Feb '24

From: Osama Muhammad <osmtendev(a)gmail.com> stable inclusion from stable-v5.10.209 commit 5c28478af371a1c3fdb570ca67f110e1ae60fc37 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I93ODT CVE: CVE-2023-52448 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8877243beafa7c6bfc42022cbfdf9e39b25bd4fa ] Syzkaller has reported a NULL pointer dereference when accessing rgd->rd_rgl in gfs2_rgrp_dump(). This can happen when creating rgd->rd_gl fails in read_rindex_entry(). Add a NULL pointer check in gfs2_rgrp_dump() to prevent that. Reported-and-tested-by: syzbot+da0fc229cc1ff4bb2e6d(a)syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=da0fc229cc1ff4bb2e6d Fixes: 72244b6bc752 ("gfs2: improve debug information when lvb mismatches are found") Signed-off-by: Osama Muhammad <osmtendev(a)gmail.com> Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/gfs2/rgrp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c index c5bde789a16d..4e760a3fb661 100644 --- a/fs/gfs2/rgrp.c +++ b/fs/gfs2/rgrp.c @@ -2231,7 +2231,7 @@ void gfs2_rgrp_dump(struct seq_file *seq, struct gfs2_rgrpd *rgd, (unsigned long long)rgd->rd_addr, rgd->rd_flags, rgd->rd_free, rgd->rd_free_clone, rgd->rd_dinodes, rgd->rd_reserved, rgd->rd_extfail_pt); - if (rgd->rd_sbd->sd_args.ar_rgrplvb) { + if (rgd->rd_sbd->sd_args.ar_rgrplvb && rgd->rd_rgl) { struct gfs2_rgrp_lvb *rgl = rgd->rd_rgl; gfs2_print_dbg(seq, "%s L: f:%02x b:%u i:%u\n", fs_id_buf, -- 2.31.1

2 1

[PATCH OLK-5.10] gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump
by Baokun Li 26 Feb '24

26 Feb '24

From: Osama Muhammad <osmtendev(a)gmail.com> stable inclusion from stable-v5.10.209 commit 5c28478af371a1c3fdb570ca67f110e1ae60fc37 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I93ODT CVE: CVE-2023-52448 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8877243beafa7c6bfc42022cbfdf9e39b25bd4fa ] Syzkaller has reported a NULL pointer dereference when accessing rgd->rd_rgl in gfs2_rgrp_dump(). This can happen when creating rgd->rd_gl fails in read_rindex_entry(). Add a NULL pointer check in gfs2_rgrp_dump() to prevent that. Reported-and-tested-by: syzbot+da0fc229cc1ff4bb2e6d(a)syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=da0fc229cc1ff4bb2e6d Fixes: 72244b6bc752 ("gfs2: improve debug information when lvb mismatches are found") Signed-off-by: Osama Muhammad <osmtendev(a)gmail.com> Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/gfs2/rgrp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c index c5bde789a16d..4e760a3fb661 100644 --- a/fs/gfs2/rgrp.c +++ b/fs/gfs2/rgrp.c @@ -2231,7 +2231,7 @@ void gfs2_rgrp_dump(struct seq_file *seq, struct gfs2_rgrpd *rgd, (unsigned long long)rgd->rd_addr, rgd->rd_flags, rgd->rd_free, rgd->rd_free_clone, rgd->rd_dinodes, rgd->rd_reserved, rgd->rd_extfail_pt); - if (rgd->rd_sbd->sd_args.ar_rgrplvb) { + if (rgd->rd_sbd->sd_args.ar_rgrplvb && rgd->rd_rgl) { struct gfs2_rgrp_lvb *rgl = rgd->rd_rgl; gfs2_print_dbg(seq, "%s L: f:%02x b:%u i:%u\n", fs_id_buf, -- 2.31.1

2 1

[PATCH OLK-6.6 0/2] fix CVE-2024-26590
by Baokun Li 26 Feb '24

26 Feb '24

Gao Xiang (2): erofs: simplify compression configuration parser erofs: fix inconsistent per-file compression format fs/erofs/compress.h | 6 +++ fs/erofs/decompressor.c | 62 ++++++++++++++++++++++++++-- fs/erofs/decompressor_deflate.c | 5 ++- fs/erofs/decompressor_lzma.c | 4 +- fs/erofs/internal.h | 38 +---------------- fs/erofs/super.c | 72 ++++----------------------------- fs/erofs/zmap.c | 23 ++++++----- 7 files changed, 92 insertions(+), 118 deletions(-) -- 2.31.1

2 3

[PATCH openEuler-1.0-LTS 0/2] Remove WQ_FLAG_BOOKMARK flag
by Zizhi Wo 26 Feb '24

26 Feb '24

Fix softlockup by removing the wait_queue flag: WQ_FLAG_BOOKMARK. Matthew Wilcox (Oracle) (2): filemap: remove use of wait bookmarks sched: remove wait bookmarks include/linux/wait.h | 3 --- kernel/sched/wait.c | 57 ++++++-------------------------------------- mm/filemap.c | 21 +--------------- 3 files changed, 8 insertions(+), 73 deletions(-) -- 2.39.2

2 3

[PATCH openEuler-1.0-LTS 0/3] CVE-2021-46904 for openEuler1.0
by Liu Jian 26 Feb '24

26 Feb '24

Anirudh Rayabharam (1): net: hso: fix null-ptr-deref during tty device unregistration Johan Hovold (1): net: hso: fix NULL-deref on disconnect regression Rustam Kovhaev (1): usb: hso: check for return value in hso_serial_common_create() drivers/net/usb/hso.c | 38 ++++++++++++++++---------------------- 1 file changed, 16 insertions(+), 22 deletions(-) -- 2.34.1

2 4

[PATCH OLK-6.6] mtd: Fix gluebi NULL pointer dereference caused by ftl notifier
by ZhaoLong Wang 26 Feb '24

26 Feb '24

stable inclusion from stable-v6.6.14 commit cfd7c9d260dc0a3baaea05a122a19ab91e193c65 category: bugfix bugzilla: 189540, https://gitee.com/src-openeuler/kernel/issues/I932W5 CVE: CVE-2023-52449 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6 ] If both ftl.ko and gluebi.ko are loaded, the notifier of ftl triggers NULL pointer dereference when trying to access ‘gluebi->desc’ in gluebi_read(). ubi_gluebi_init ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all gluebi_notify nb->notifier_call() gluebi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add() ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std gluebi_read mtd->read() gluebi->desc - NULL Detailed reproduction information available at the Link [1], In the normal case, obtain gluebi->desc in the gluebi_get_device(), and access gluebi->desc in the gluebi_read(). However, gluebi_get_device() is not executed in advance in the ftl_add_mtd() process, which leads to NULL pointer dereference. The solution for the gluebi module is to run jffs2 on the UBI volume without considering working with ftl or mtdblock [2]. Therefore, this problem can be avoided by preventing gluebi from creating the mtdblock device after creating mtd partition of the type MTD_UBIVOLUME. Fixes: 2ba3d76a1e29 ("UBI: make gluebi a separate module") Link: https://bugzilla.kernel.org/show_bug.cgi?id=217992 [1] Link: https://lore.kernel.org/lkml/441107100.23734.1697904580252.JavaMail.zimbra@… [2] Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> Reviewed-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Acked-by: Richard Weinberger <richard(a)nod.at> Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> Link: https://lore.kernel.org/linux-mtd/20231220024619.2138625-1-wangzhaolong1@hu… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- drivers/mtd/mtd_blkdevs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c index ff18636e0889..5bc32108ca03 100644 --- a/drivers/mtd/mtd_blkdevs.c +++ b/drivers/mtd/mtd_blkdevs.c @@ -463,7 +463,7 @@ static void blktrans_notify_add(struct mtd_info *mtd) { struct mtd_blktrans_ops *tr; - if (mtd->type == MTD_ABSENT) + if (mtd->type == MTD_ABSENT || mtd->type == MTD_UBIVOLUME) return; list_for_each_entry(tr, &blktrans_majors, list) @@ -503,7 +503,7 @@ int register_mtd_blktrans(struct mtd_blktrans_ops *tr) mutex_lock(&mtd_table_mutex); list_add(&tr->list, &blktrans_majors); mtd_for_each_device(mtd) - if (mtd->type != MTD_ABSENT) + if (mtd->type != MTD_ABSENT && mtd->type != MTD_UBIVOLUME) tr->add_mtd(tr, mtd); mutex_unlock(&mtd_table_mutex); return 0; -- 2.39.2

2 1

[PATCH OLK-6.6] gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump
by Baokun Li 26 Feb '24

26 Feb '24

From: Osama Muhammad <osmtendev(a)gmail.com> stable inclusion from stable-v6.6.14 commit 067a7c48c2c70f05f9460d6f0e8423e234729f05 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I93ODT CVE: CVE-2023-52448 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 8877243beafa7c6bfc42022cbfdf9e39b25bd4fa ] Syzkaller has reported a NULL pointer dereference when accessing rgd->rd_rgl in gfs2_rgrp_dump(). This can happen when creating rgd->rd_gl fails in read_rindex_entry(). Add a NULL pointer check in gfs2_rgrp_dump() to prevent that. Reported-and-tested-by: syzbot+da0fc229cc1ff4bb2e6d(a)syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=da0fc229cc1ff4bb2e6d Fixes: 72244b6bc752 ("gfs2: improve debug information when lvb mismatches are found") Signed-off-by: Osama Muhammad <osmtendev(a)gmail.com> Signed-off-by: Andreas Gruenbacher <agruenba(a)redhat.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/gfs2/rgrp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/gfs2/rgrp.c b/fs/gfs2/rgrp.c index 9308190895c8..307b952a41f8 100644 --- a/fs/gfs2/rgrp.c +++ b/fs/gfs2/rgrp.c @@ -2306,7 +2306,7 @@ void gfs2_rgrp_dump(struct seq_file *seq, struct gfs2_rgrpd *rgd, (unsigned long long)rgd->rd_addr, rgd->rd_flags, rgd->rd_free, rgd->rd_free_clone, rgd->rd_dinodes, rgd->rd_requested, rgd->rd_reserved, rgd->rd_extfail_pt); - if (rgd->rd_sbd->sd_args.ar_rgrplvb) { + if (rgd->rd_sbd->sd_args.ar_rgrplvb && rgd->rd_rgl) { struct gfs2_rgrp_lvb *rgl = rgd->rd_rgl; gfs2_print_dbg(seq, "%s L: f:%02x b:%u i:%u\n", fs_id_buf, -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS] mtd: Fix gluebi NULL pointer dereference caused by ftl notifier
by ZhaoLong Wang 26 Feb '24

26 Feb '24

stable inclusion from stable-v4.19.306 commit aeba358bcc8ffddf9b4a9bd0e5ec9eb338d46022 category: bugfix bugzilla: 189540, https://gitee.com/src-openeuler/kernel/issues/I932W5 CVE: CVE-2023-52449 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6 ] If both ftl.ko and gluebi.ko are loaded, the notifier of ftl triggers NULL pointer dereference when trying to access ‘gluebi->desc’ in gluebi_read(). ubi_gluebi_init ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all gluebi_notify nb->notifier_call() gluebi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add() ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std gluebi_read mtd->read() gluebi->desc - NULL Detailed reproduction information available at the Link [1], In the normal case, obtain gluebi->desc in the gluebi_get_device(), and access gluebi->desc in the gluebi_read(). However, gluebi_get_device() is not executed in advance in the ftl_add_mtd() process, which leads to NULL pointer dereference. The solution for the gluebi module is to run jffs2 on the UBI volume without considering working with ftl or mtdblock [2]. Therefore, this problem can be avoided by preventing gluebi from creating the mtdblock device after creating mtd partition of the type MTD_UBIVOLUME. Fixes: 2ba3d76a1e29 ("UBI: make gluebi a separate module") Link: https://bugzilla.kernel.org/show_bug.cgi?id=217992 [1] Link: https://lore.kernel.org/lkml/441107100.23734.1697904580252.JavaMail.zimbra@… [2] Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> Reviewed-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Acked-by: Richard Weinberger <richard(a)nod.at> Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> Link: https://lore.kernel.org/linux-mtd/20231220024619.2138625-1-wangzhaolong1@hu… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- drivers/mtd/mtd_blkdevs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c index 29c0bfd74e8a..40b2cbd8a0b5 100644 --- a/drivers/mtd/mtd_blkdevs.c +++ b/drivers/mtd/mtd_blkdevs.c @@ -521,7 +521,7 @@ static void blktrans_notify_add(struct mtd_info *mtd) { struct mtd_blktrans_ops *tr; - if (mtd->type == MTD_ABSENT) + if (mtd->type == MTD_ABSENT || mtd->type == MTD_UBIVOLUME) return; list_for_each_entry(tr, &blktrans_majors, list) @@ -564,7 +564,7 @@ int register_mtd_blktrans(struct mtd_blktrans_ops *tr) list_add(&tr->list, &blktrans_majors); mtd_for_each_device(mtd) - if (mtd->type != MTD_ABSENT) + if (mtd->type != MTD_ABSENT && mtd->type != MTD_UBIVOLUME) tr->add_mtd(tr, mtd); mutex_unlock(&mtd_table_mutex); -- 2.39.2

2 1

[PATCH OLK-5.10] mtd: Fix gluebi NULL pointer dereference caused by ftl notifier
by ZhaoLong Wang 26 Feb '24

26 Feb '24

stable inclusion from stable-v5.10.209 commit 001a3f59d8c914ef8273461d4bf495df384cc5f8 category: bugfix bugzilla: 189540, https://gitee.com/src-openeuler/kernel/issues/I932W5 CVE: CVE-2023-52449 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6 ] If both ftl.ko and gluebi.ko are loaded, the notifier of ftl triggers NULL pointer dereference when trying to access ‘gluebi->desc’ in gluebi_read(). ubi_gluebi_init ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all gluebi_notify nb->notifier_call() gluebi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add() ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std gluebi_read mtd->read() gluebi->desc - NULL Detailed reproduction information available at the Link [1], In the normal case, obtain gluebi->desc in the gluebi_get_device(), and access gluebi->desc in the gluebi_read(). However, gluebi_get_device() is not executed in advance in the ftl_add_mtd() process, which leads to NULL pointer dereference. The solution for the gluebi module is to run jffs2 on the UBI volume without considering working with ftl or mtdblock [2]. Therefore, this problem can be avoided by preventing gluebi from creating the mtdblock device after creating mtd partition of the type MTD_UBIVOLUME. Fixes: 2ba3d76a1e29 ("UBI: make gluebi a separate module") Link: https://bugzilla.kernel.org/show_bug.cgi?id=217992 [1] Link: https://lore.kernel.org/lkml/441107100.23734.1697904580252.JavaMail.zimbra@… [2] Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> Reviewed-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Acked-by: Richard Weinberger <richard(a)nod.at> Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> Link: https://lore.kernel.org/linux-mtd/20231220024619.2138625-1-wangzhaolong1@hu… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/mtd/mtd_blkdevs.c Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- drivers/mtd/mtd_blkdevs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c index 5b5504e123a6..3c79cd67478a 100644 --- a/drivers/mtd/mtd_blkdevs.c +++ b/drivers/mtd/mtd_blkdevs.c @@ -527,7 +527,7 @@ static void blktrans_notify_add(struct mtd_info *mtd) { struct mtd_blktrans_ops *tr; - if (mtd->type == MTD_ABSENT) + if (mtd->type == MTD_ABSENT || mtd->type == MTD_UBIVOLUME) return; list_for_each_entry(tr, &blktrans_majors, list) @@ -570,7 +570,7 @@ int register_mtd_blktrans(struct mtd_blktrans_ops *tr) list_add(&tr->list, &blktrans_majors); mtd_for_each_device(mtd) - if (mtd->type != MTD_ABSENT) + if (mtd->type != MTD_ABSENT && mtd->type != MTD_UBIVOLUME) tr->add_mtd(tr, mtd); mtd_table_mutex_unlock(); -- 2.39.2

2 1

[PATCH OLK-5.10 0/2] Remove WQ_FLAG_BOOKMARK flag
by Zizhi Wo 26 Feb '24

26 Feb '24

Fix softlockup by removing the wait_queue flag: WQ_FLAG_BOOKMARK. Matthew Wilcox (Oracle) (2): filemap: remove use of wait bookmarks sched: remove wait bookmarks include/linux/wait.h | 3 --- kernel/sched/wait.c | 59 ++++++++------------------------------------ mm/filemap.c | 21 +--------------- 3 files changed, 11 insertions(+), 72 deletions(-) -- 2.39.2

2 3

[PATCH openEuler-1.0-LTS 0/1] i2c: i801: Fix block process call transactions
by Liao Chen 26 Feb '24

26 Feb '24

According to the Intel datasheets, software must reset the block buffer index twice for block process call transactions: once before writing the outgoing data to the buffer, and once again before reading the incoming data from the buffer. The driver is currently missing the second reset, causing the wrong portion of the block buffer to be read. Jean Delvare (1): i2c: i801: Fix block process call transactions drivers/i2c/busses/i2c-i801.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS] mtd: Fix gluebi NULL pointer dereference caused by ftl notifier
by ZhaoLong Wang 26 Feb '24

26 Feb '24

stable inclusion from stable-v4.19.306 commit aeba358bcc8ffddf9b4a9bd0e5ec9eb338d46022 category: bugfix bugzilla: 189540 CVE: CVE-2023-52449 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6 ] If both ftl.ko and gluebi.ko are loaded, the notifier of ftl triggers NULL pointer dereference when trying to access ‘gluebi->desc’ in gluebi_read(). ubi_gluebi_init ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all gluebi_notify nb->notifier_call() gluebi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add() ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std gluebi_read mtd->read() gluebi->desc - NULL Detailed reproduction information available at the Link [1], In the normal case, obtain gluebi->desc in the gluebi_get_device(), and access gluebi->desc in the gluebi_read(). However, gluebi_get_device() is not executed in advance in the ftl_add_mtd() process, which leads to NULL pointer dereference. The solution for the gluebi module is to run jffs2 on the UBI volume without considering working with ftl or mtdblock [2]. Therefore, this problem can be avoided by preventing gluebi from creating the mtdblock device after creating mtd partition of the type MTD_UBIVOLUME. Fixes: 2ba3d76a1e29 ("UBI: make gluebi a separate module") Link: https://bugzilla.kernel.org/show_bug.cgi?id=217992 [1] Link: https://lore.kernel.org/lkml/441107100.23734.1697904580252.JavaMail.zimbra@… [2] Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> Reviewed-by: Zhihao Cheng <chengzhihao1(a)huawei.com> Acked-by: Richard Weinberger <richard(a)nod.at> Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> Link: https://lore.kernel.org/linux-mtd/20231220024619.2138625-1-wangzhaolong1@hu… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: ZhaoLong Wang <wangzhaolong1(a)huawei.com> --- drivers/mtd/mtd_blkdevs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c index 29c0bfd74e8a..40b2cbd8a0b5 100644 --- a/drivers/mtd/mtd_blkdevs.c +++ b/drivers/mtd/mtd_blkdevs.c @@ -521,7 +521,7 @@ static void blktrans_notify_add(struct mtd_info *mtd) { struct mtd_blktrans_ops *tr; - if (mtd->type == MTD_ABSENT) + if (mtd->type == MTD_ABSENT || mtd->type == MTD_UBIVOLUME) return; list_for_each_entry(tr, &blktrans_majors, list) @@ -564,7 +564,7 @@ int register_mtd_blktrans(struct mtd_blktrans_ops *tr) list_add(&tr->list, &blktrans_majors); mtd_for_each_device(mtd) - if (mtd->type != MTD_ABSENT) + if (mtd->type != MTD_ABSENT && mtd->type != MTD_UBIVOLUME) tr->add_mtd(tr, mtd); mutex_unlock(&mtd_table_mutex); -- 2.39.2

2 1

[PATCH OLK-5.10] efivarfs: force RO when remounting if SetVariable is not supported
by Zhihao Cheng 26 Feb '24

26 Feb '24

From: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> stable inclusion from stable-v5.10.210 commit 94c742324ed7e42c5bd6a9ed22e4ec6d764db4d8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93EC7 CVE: CVE-2023-52463 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 0e8d2444168dd519fea501599d150e62718ed2fe upstream. If SetVariable at runtime is not supported by the firmware we never assign a callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a crash looking like this: $ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04: level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 303.292123] pc : 0x0 [ 303.292443] lr : efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [ 303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585] efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [ 303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156] el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [ 303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] Code: ???????? ???????? ???????? ???????? (????????) [ 303.310612] ---[ end trace 0000000000000000 ]--- Fix this by adding a .reconfigure() function to the fs operations which we can use to check the requested flags and deny anything that's not RO if the firmware doesn't implement SetVariable at runtime. Fixes: f88814cc2578 ("efi/efivars: Expose RT service availability via efivars abstraction") Signed-off-by: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> --- fs/efivarfs/super.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c index 15880a68faad..3626816b174a 100644 --- a/fs/efivarfs/super.c +++ b/fs/efivarfs/super.c @@ -13,6 +13,7 @@ #include <linux/ucs2_string.h> #include <linux/slab.h> #include <linux/magic.h> +#include <linux/printk.h> #include "internal.h" @@ -231,8 +232,19 @@ static int efivarfs_get_tree(struct fs_context *fc) return get_tree_single(fc, efivarfs_fill_super); } +static int efivarfs_reconfigure(struct fs_context *fc) +{ + if (!efivar_supports_writes() && !(fc->sb_flags & SB_RDONLY)) { + pr_err("Firmware does not support SetVariableRT. Can not remount with rw\n"); + return -EINVAL; + } + + return 0; +} + static const struct fs_context_operations efivarfs_context_ops = { .get_tree = efivarfs_get_tree, + .reconfigure = efivarfs_reconfigure, }; static int efivarfs_init_fs_context(struct fs_context *fc) -- 2.31.1

2 1

[PATCH openEuler-1.0-LTS v2] mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path
by Zhengchao Shao 26 Feb '24

26 Feb '24

From: Ido Schimmel <idosch(a)nvidia.com> mainline inclusion from mainline-v6.8-rc1 commit efeb7dfea8ee10cdec11b6b6ba4e405edbe75809 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93EE7 CVE: CVE-2024-26595 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after failing to attach the region to an ACL group, we hit a NULL pointer dereference upon 'region->group->tcam' [1]. Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0 [...] Call Trace: mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fixes: 22a677661f56 ("mlxsw: spectrum: Introduce ACL core with simple TCAM implementation") Signed-off-by: Ido Schimmel <idosch(a)nvidia.com> Reviewed-by: Amit Cohen <amcohen(a)nvidia.com> Reviewed-by: Jiri Pirko <jiri(a)nvidia.com> Signed-off-by: Petr Machata <petrm(a)nvidia.com> Acked-by: Paolo Abeni <pabeni(a)redhat.com> Link: https://lore.kernel.org/r/fb6a4542bbc9fcab5a523802d97059bffbca7126.17055020… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/ethernet/mellanox/mlxsw/spectrum.h drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 1 + drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c | 5 +++++ drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c | 3 ++- 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h index 3cdb7aca90b7..7d2978223c16 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h @@ -491,6 +491,7 @@ enum mlxsw_sp_acl_profile { }; struct mlxsw_afk *mlxsw_sp_acl_afk(struct mlxsw_sp_acl *acl); +struct mlxsw_sp_acl_tcam *mlxsw_sp_acl_to_tcam(struct mlxsw_sp_acl *acl); struct mlxsw_sp *mlxsw_sp_acl_block_mlxsw_sp(struct mlxsw_sp_acl_block *block); unsigned int mlxsw_sp_acl_block_rule_count(struct mlxsw_sp_acl_block *block); void mlxsw_sp_acl_block_disable_inc(struct mlxsw_sp_acl_block *block); diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c index c99f5542da1e..22ba0600ccb5 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c @@ -38,6 +38,11 @@ struct mlxsw_afk *mlxsw_sp_acl_afk(struct mlxsw_sp_acl *acl) return acl->afk; } +struct mlxsw_sp_acl_tcam *mlxsw_sp_acl_to_tcam(struct mlxsw_sp_acl *acl) +{ + return &acl->tcam; +} + struct mlxsw_sp_acl_block_binding { struct list_head list; struct net_device *dev; diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c index 30931a2c025b..1c961fd5cffa 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c @@ -571,12 +571,13 @@ static void mlxsw_sp_acl_tcam_region_destroy(struct mlxsw_sp *mlxsw_sp, struct mlxsw_sp_acl_tcam_region *region) { + struct mlxsw_sp_acl_tcam *tcam = mlxsw_sp_acl_to_tcam(mlxsw_sp->acl); const struct mlxsw_sp_acl_tcam_ops *ops = mlxsw_sp->acl_tcam_ops; ops->region_fini(mlxsw_sp, region->priv); mlxsw_sp_acl_tcam_region_disable(mlxsw_sp, region); mlxsw_sp_acl_tcam_region_free(mlxsw_sp, region); - mlxsw_sp_acl_tcam_region_id_put(region->group->tcam, region->id); + mlxsw_sp_acl_tcam_region_id_put(tcam, region->id); mlxsw_afk_key_info_put(region->key_info); kfree(region); } -- 2.34.1

2 1

[PATCH OLK-6.6] efivarfs: force RO when remounting if SetVariable is not supported
by Zhihao Cheng 26 Feb '24

26 Feb '24

From: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> stable inclusion from stable-v6.6.14 commit 0049fe7e4a85849bdd778cdb72e51a791ff3d737 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93EC7 CVE: CVE-2023-52463 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- commit 0e8d2444168dd519fea501599d150e62718ed2fe upstream. If SetVariable at runtime is not supported by the firmware we never assign a callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a crash looking like this: $ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04: level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 303.292123] pc : 0x0 [ 303.292443] lr : efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [ 303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585] efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [ 303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156] el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [ 303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] Code: ???????? ???????? ???????? ???????? (????????) [ 303.310612] ---[ end trace 0000000000000000 ]--- Fix this by adding a .reconfigure() function to the fs operations which we can use to check the requested flags and deny anything that's not RO if the firmware doesn't implement SetVariable at runtime. Fixes: f88814cc2578 ("efi/efivars: Expose RT service availability via efivars abstraction") Signed-off-by: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> --- fs/efivarfs/super.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c index 996271473609..05c01694e852 100644 --- a/fs/efivarfs/super.c +++ b/fs/efivarfs/super.c @@ -14,6 +14,7 @@ #include <linux/slab.h> #include <linux/magic.h> #include <linux/statfs.h> +#include <linux/printk.h> #include "internal.h" @@ -275,8 +276,19 @@ static int efivarfs_get_tree(struct fs_context *fc) return get_tree_single(fc, efivarfs_fill_super); } +static int efivarfs_reconfigure(struct fs_context *fc) +{ + if (!efivar_supports_writes() && !(fc->sb_flags & SB_RDONLY)) { + pr_err("Firmware does not support SetVariableRT. Can not remount with rw\n"); + return -EINVAL; + } + + return 0; +} + static const struct fs_context_operations efivarfs_context_ops = { .get_tree = efivarfs_get_tree, + .reconfigure = efivarfs_reconfigure, }; static int efivarfs_init_fs_context(struct fs_context *fc) -- 2.31.1

2 1

[PATCH OLK-5.10] efivarfs: force RO when remounting if SetVariable is not supported
by Zhihao Cheng 26 Feb '24

26 Feb '24

From: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> stable inclusion from stable-v5.10.210 commit 94c742324ed7e42c5bd6a9ed22e4ec6d764db4d8 category: bugfix bugzilla: 189543 CVE: CVE-2023-52463 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 0e8d2444168dd519fea501599d150e62718ed2fe upstream. If SetVariable at runtime is not supported by the firmware we never assign a callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a crash looking like this: $ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04: level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 303.292123] pc : 0x0 [ 303.292443] lr : efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [ 303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585] efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [ 303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156] el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [ 303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] Code: ???????? ???????? ???????? ???????? (????????) [ 303.310612] ---[ end trace 0000000000000000 ]--- Fix this by adding a .reconfigure() function to the fs operations which we can use to check the requested flags and deny anything that's not RO if the firmware doesn't implement SetVariable at runtime. Fixes: f88814cc2578 ("efi/efivars: Expose RT service availability via efivars abstraction") Signed-off-by: Ilias Apalodimas <ilias.apalodimas(a)linaro.org> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com> --- fs/efivarfs/super.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c index 15880a68faad..3626816b174a 100644 --- a/fs/efivarfs/super.c +++ b/fs/efivarfs/super.c @@ -13,6 +13,7 @@ #include <linux/ucs2_string.h> #include <linux/slab.h> #include <linux/magic.h> +#include <linux/printk.h> #include "internal.h" @@ -231,8 +232,19 @@ static int efivarfs_get_tree(struct fs_context *fc) return get_tree_single(fc, efivarfs_fill_super); } +static int efivarfs_reconfigure(struct fs_context *fc) +{ + if (!efivar_supports_writes() && !(fc->sb_flags & SB_RDONLY)) { + pr_err("Firmware does not support SetVariableRT. Can not remount with rw\n"); + return -EINVAL; + } + + return 0; +} + static const struct fs_context_operations efivarfs_context_ops = { .get_tree = efivarfs_get_tree, + .reconfigure = efivarfs_reconfigure, }; static int efivarfs_init_fs_context(struct fs_context *fc) -- 2.31.1

2 1

[PATCH openEuler-22.03-LTS] ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()
by Yuntao Liu 26 Feb '24

26 Feb '24

From: Tuo Li <islituo(a)gmail.com> stable inclusion from stable-v5.10.192 commit 9f9eed451176ffcac6b5ba0f6dae1a6b4a1cb0eb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I917HR CVE: CVE-2024-23196 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1f4a08fed450db87fbb5ff5105354158bdbe1a22 ] The variable codec->regmap is often protected by the lock codec->regmap_lock when is accessed. However, it is accessed without holding the lock when is accessed in snd_hdac_regmap_sync(): if (codec->regmap) In my opinion, this may be a harmful race, because if codec->regmap is set to NULL right after the condition is checked, a null-pointer dereference can occur in the called function regcache_sync(): map->lock(map->lock_arg); --> Line 360 in drivers/base/regmap/regcache.c To fix this possible null-pointer dereference caused by data race, the mutex_lock coverage is extended to protect the if statement as well as the function call to regcache_sync(). [ Note: the lack of the regmap_lock itself is harmless for the current codec driver implementations, as snd_hdac_regmap_sync() is only for PM runtime resume that is prohibited during the codec probe. But the change makes the whole code more consistent, so it's merged as is -- tiwai ] Reported-by: BassCheck <bass(a)buaa.edu.cn> Signed-off-by: Tuo Li <islituo(a)gmail.com> Link: https://lore.kernel.org/r/20230703031016.1184711-1-islituo@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Yuntao Liu <liuyuntao12(a)huawei.com> --- sound/hda/hdac_regmap.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/sound/hda/hdac_regmap.c b/sound/hda/hdac_regmap.c index f258cb3a6895..9b1bcabd8414 100644 --- a/sound/hda/hdac_regmap.c +++ b/sound/hda/hdac_regmap.c @@ -596,10 +596,9 @@ EXPORT_SYMBOL_GPL(snd_hdac_regmap_update_raw_once); */ void snd_hdac_regmap_sync(struct hdac_device *codec) { - if (codec->regmap) { - mutex_lock(&codec->regmap_lock); + mutex_lock(&codec->regmap_lock); + if (codec->regmap) regcache_sync(codec->regmap); - mutex_unlock(&codec->regmap_lock); - } + mutex_unlock(&codec->regmap_lock); } EXPORT_SYMBOL_GPL(snd_hdac_regmap_sync); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()
by Yuntao Liu 26 Feb '24

26 Feb '24

From: Tuo Li <islituo(a)gmail.com> stable inclusion from stable-v5.10.192 commit 9f9eed451176ffcac6b5ba0f6dae1a6b4a1cb0eb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I917HR CVE: CVE-2024-23196 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1f4a08fed450db87fbb5ff5105354158bdbe1a22 ] The variable codec->regmap is often protected by the lock codec->regmap_lock when is accessed. However, it is accessed without holding the lock when is accessed in snd_hdac_regmap_sync(): if (codec->regmap) In my opinion, this may be a harmful race, because if codec->regmap is set to NULL right after the condition is checked, a null-pointer dereference can occur in the called function regcache_sync(): map->lock(map->lock_arg); --> Line 360 in drivers/base/regmap/regcache.c To fix this possible null-pointer dereference caused by data race, the mutex_lock coverage is extended to protect the if statement as well as the function call to regcache_sync(). [ Note: the lack of the regmap_lock itself is harmless for the current codec driver implementations, as snd_hdac_regmap_sync() is only for PM runtime resume that is prohibited during the codec probe. But the change makes the whole code more consistent, so it's merged as is -- tiwai ] Reported-by: BassCheck <bass(a)buaa.edu.cn> Signed-off-by: Tuo Li <islituo(a)gmail.com> Link: https://lore.kernel.org/r/20230703031016.1184711-1-islituo@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Yuntao Liu <liuyuntao12(a)huawei.com> --- sound/hda/hdac_regmap.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/sound/hda/hdac_regmap.c b/sound/hda/hdac_regmap.c index f258cb3a6895..9b1bcabd8414 100644 --- a/sound/hda/hdac_regmap.c +++ b/sound/hda/hdac_regmap.c @@ -596,10 +596,9 @@ EXPORT_SYMBOL_GPL(snd_hdac_regmap_update_raw_once); */ void snd_hdac_regmap_sync(struct hdac_device *codec) { - if (codec->regmap) { - mutex_lock(&codec->regmap_lock); + mutex_lock(&codec->regmap_lock); + if (codec->regmap) regcache_sync(codec->regmap); - mutex_unlock(&codec->regmap_lock); - } + mutex_unlock(&codec->regmap_lock); } EXPORT_SYMBOL_GPL(snd_hdac_regmap_sync); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP2] ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()
by Yuntao Liu 26 Feb '24

26 Feb '24

From: Tuo Li <islituo(a)gmail.com> stable inclusion from stable-v5.10.192 commit 9f9eed451176ffcac6b5ba0f6dae1a6b4a1cb0eb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I917HR CVE: CVE-2024-23196 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1f4a08fed450db87fbb5ff5105354158bdbe1a22 ] The variable codec->regmap is often protected by the lock codec->regmap_lock when is accessed. However, it is accessed without holding the lock when is accessed in snd_hdac_regmap_sync(): if (codec->regmap) In my opinion, this may be a harmful race, because if codec->regmap is set to NULL right after the condition is checked, a null-pointer dereference can occur in the called function regcache_sync(): map->lock(map->lock_arg); --> Line 360 in drivers/base/regmap/regcache.c To fix this possible null-pointer dereference caused by data race, the mutex_lock coverage is extended to protect the if statement as well as the function call to regcache_sync(). [ Note: the lack of the regmap_lock itself is harmless for the current codec driver implementations, as snd_hdac_regmap_sync() is only for PM runtime resume that is prohibited during the codec probe. But the change makes the whole code more consistent, so it's merged as is -- tiwai ] Reported-by: BassCheck <bass(a)buaa.edu.cn> Signed-off-by: Tuo Li <islituo(a)gmail.com> Link: https://lore.kernel.org/r/20230703031016.1184711-1-islituo@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Yuntao Liu <liuyuntao12(a)huawei.com> --- sound/hda/hdac_regmap.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/sound/hda/hdac_regmap.c b/sound/hda/hdac_regmap.c index f258cb3a6895..9b1bcabd8414 100644 --- a/sound/hda/hdac_regmap.c +++ b/sound/hda/hdac_regmap.c @@ -596,10 +596,9 @@ EXPORT_SYMBOL_GPL(snd_hdac_regmap_update_raw_once); */ void snd_hdac_regmap_sync(struct hdac_device *codec) { - if (codec->regmap) { - mutex_lock(&codec->regmap_lock); + mutex_lock(&codec->regmap_lock); + if (codec->regmap) regcache_sync(codec->regmap); - mutex_unlock(&codec->regmap_lock); - } + mutex_unlock(&codec->regmap_lock); } EXPORT_SYMBOL_GPL(snd_hdac_regmap_sync); -- 2.34.1

2 1

[PATCH OLK-5.10 0/2] Remove WQ_FLAG_BOOKMARK flag
by Zizhi Wo 26 Feb '24

26 Feb '24

Fix softlockup by removing the wait_queue flag: WQ_FLAG_BOOKMARK. Matthew Wilcox (Oracle) (2): filemap: remove use of wait bookmarks sched: remove wait bookmarks include/linux/wait.h | 2 -- kernel/sched/wait.c | 59 ++++++++------------------------------------ mm/filemap.c | 21 +--------------- 3 files changed, 11 insertions(+), 71 deletions(-) -- 2.39.2

2 3

[PATCH OLK-5.10 v2] mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path
by Zhengchao Shao 26 Feb '24

26 Feb '24

From: Ido Schimmel <idosch(a)nvidia.com> mainline inclusion from mainline-v6.8-rc1 commit efeb7dfea8ee10cdec11b6b6ba4e405edbe75809 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93EE7 CVE: CVE-2024-26595 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after failing to attach the region to an ACL group, we hit a NULL pointer dereference upon 'region->group->tcam' [1]. Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0 [...] Call Trace: mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fixes: 22a677661f56 ("mlxsw: spectrum: Introduce ACL core with simple TCAM implementation") Signed-off-by: Ido Schimmel <idosch(a)nvidia.com> Reviewed-by: Amit Cohen <amcohen(a)nvidia.com> Reviewed-by: Jiri Pirko <jiri(a)nvidia.com> Signed-off-by: Petr Machata <petrm(a)nvidia.com> Acked-by: Paolo Abeni <pabeni(a)redhat.com> Link: https://lore.kernel.org/r/fb6a4542bbc9fcab5a523802d97059bffbca7126.17055020… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/ethernet/mellanox/mlxsw/spectrum.h drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 1 + drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c | 5 +++++ drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c | 4 ++-- 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h index 3e7576e671df..a4e229210b93 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h @@ -850,6 +850,7 @@ enum mlxsw_sp_acl_profile { }; struct mlxsw_afk *mlxsw_sp_acl_afk(struct mlxsw_sp_acl *acl); +struct mlxsw_sp_acl_tcam *mlxsw_sp_acl_to_tcam(struct mlxsw_sp_acl *acl); int mlxsw_sp_acl_ruleset_bind(struct mlxsw_sp *mlxsw_sp, struct mlxsw_sp_flow_block *block, diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c index 8cfa03a75374..9209562a5007 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c @@ -40,6 +40,11 @@ struct mlxsw_afk *mlxsw_sp_acl_afk(struct mlxsw_sp_acl *acl) return acl->afk; } +struct mlxsw_sp_acl_tcam *mlxsw_sp_acl_to_tcam(struct mlxsw_sp_acl *acl) +{ + return &acl->tcam; +} + struct mlxsw_sp_acl_ruleset_ht_key { struct mlxsw_sp_flow_block *block; u32 chain_index; diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c index 7cccc41dd69c..ddf7e03c6b43 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c @@ -744,13 +744,13 @@ static void mlxsw_sp_acl_tcam_region_destroy(struct mlxsw_sp *mlxsw_sp, struct mlxsw_sp_acl_tcam_region *region) { + struct mlxsw_sp_acl_tcam *tcam = mlxsw_sp_acl_to_tcam(mlxsw_sp->acl); const struct mlxsw_sp_acl_tcam_ops *ops = mlxsw_sp->acl_tcam_ops; ops->region_fini(mlxsw_sp, region->priv); mlxsw_sp_acl_tcam_region_disable(mlxsw_sp, region); mlxsw_sp_acl_tcam_region_free(mlxsw_sp, region); - mlxsw_sp_acl_tcam_region_id_put(region->group->tcam, - region->id); + mlxsw_sp_acl_tcam_region_id_put(tcam, region->id); kfree(region); } -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP2] ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()
by Yuntao Liu 26 Feb '24

26 Feb '24

From: Tuo Li <islituo(a)gmail.com> stable inclusion from stable-v5.10.192 commit 9f9eed451176ffcac6b5ba0f6dae1a6b4a1cb0eb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I917HR CVE: CVE-2024-23196 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1f4a08fed450db87fbb5ff5105354158bdbe1a22 ] The variable codec->regmap is often protected by the lock codec->regmap_lock when is accessed. However, it is accessed without holding the lock when is accessed in snd_hdac_regmap_sync(): if (codec->regmap) In my opinion, this may be a harmful race, because if codec->regmap is set to NULL right after the condition is checked, a null-pointer dereference can occur in the called function regcache_sync(): map->lock(map->lock_arg); --> Line 360 in drivers/base/regmap/regcache.c To fix this possible null-pointer dereference caused by data race, the mutex_lock coverage is extended to protect the if statement as well as the function call to regcache_sync(). [ Note: the lack of the regmap_lock itself is harmless for the current codec driver implementations, as snd_hdac_regmap_sync() is only for PM runtime resume that is prohibited during the codec probe. But the change makes the whole code more consistent, so it's merged as is -- tiwai ] Reported-by: BassCheck <bass(a)buaa.edu.cn> Signed-off-by: Tuo Li <islituo(a)gmail.com> Link: https://lore.kernel.org/r/20230703031016.1184711-1-islituo@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/hda/hdac_regmap.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/sound/hda/hdac_regmap.c b/sound/hda/hdac_regmap.c index f258cb3a6895..9b1bcabd8414 100644 --- a/sound/hda/hdac_regmap.c +++ b/sound/hda/hdac_regmap.c @@ -596,10 +596,9 @@ EXPORT_SYMBOL_GPL(snd_hdac_regmap_update_raw_once); */ void snd_hdac_regmap_sync(struct hdac_device *codec) { - if (codec->regmap) { - mutex_lock(&codec->regmap_lock); + mutex_lock(&codec->regmap_lock); + if (codec->regmap) regcache_sync(codec->regmap); - mutex_unlock(&codec->regmap_lock); - } + mutex_unlock(&codec->regmap_lock); } EXPORT_SYMBOL_GPL(snd_hdac_regmap_sync); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS-SP1] ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()
by Yuntao Liu 26 Feb '24

26 Feb '24

From: Tuo Li <islituo(a)gmail.com> stable inclusion from stable-v5.10.192 commit 9f9eed451176ffcac6b5ba0f6dae1a6b4a1cb0eb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I917HR CVE: CVE-2024-23196 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1f4a08fed450db87fbb5ff5105354158bdbe1a22 ] The variable codec->regmap is often protected by the lock codec->regmap_lock when is accessed. However, it is accessed without holding the lock when is accessed in snd_hdac_regmap_sync(): if (codec->regmap) In my opinion, this may be a harmful race, because if codec->regmap is set to NULL right after the condition is checked, a null-pointer dereference can occur in the called function regcache_sync(): map->lock(map->lock_arg); --> Line 360 in drivers/base/regmap/regcache.c To fix this possible null-pointer dereference caused by data race, the mutex_lock coverage is extended to protect the if statement as well as the function call to regcache_sync(). [ Note: the lack of the regmap_lock itself is harmless for the current codec driver implementations, as snd_hdac_regmap_sync() is only for PM runtime resume that is prohibited during the codec probe. But the change makes the whole code more consistent, so it's merged as is -- tiwai ] Reported-by: BassCheck <bass(a)buaa.edu.cn> Signed-off-by: Tuo Li <islituo(a)gmail.com> Link: https://lore.kernel.org/r/20230703031016.1184711-1-islituo@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/hda/hdac_regmap.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/sound/hda/hdac_regmap.c b/sound/hda/hdac_regmap.c index f258cb3a6895..9b1bcabd8414 100644 --- a/sound/hda/hdac_regmap.c +++ b/sound/hda/hdac_regmap.c @@ -596,10 +596,9 @@ EXPORT_SYMBOL_GPL(snd_hdac_regmap_update_raw_once); */ void snd_hdac_regmap_sync(struct hdac_device *codec) { - if (codec->regmap) { - mutex_lock(&codec->regmap_lock); + mutex_lock(&codec->regmap_lock); + if (codec->regmap) regcache_sync(codec->regmap); - mutex_unlock(&codec->regmap_lock); - } + mutex_unlock(&codec->regmap_lock); } EXPORT_SYMBOL_GPL(snd_hdac_regmap_sync); -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS] ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()
by Yuntao Liu 26 Feb '24

26 Feb '24

From: Tuo Li <islituo(a)gmail.com> stable inclusion from stable-v5.10.192 commit 9f9eed451176ffcac6b5ba0f6dae1a6b4a1cb0eb category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I917HR CVE: CVE-2024-23196 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 1f4a08fed450db87fbb5ff5105354158bdbe1a22 ] The variable codec->regmap is often protected by the lock codec->regmap_lock when is accessed. However, it is accessed without holding the lock when is accessed in snd_hdac_regmap_sync(): if (codec->regmap) In my opinion, this may be a harmful race, because if codec->regmap is set to NULL right after the condition is checked, a null-pointer dereference can occur in the called function regcache_sync(): map->lock(map->lock_arg); --> Line 360 in drivers/base/regmap/regcache.c To fix this possible null-pointer dereference caused by data race, the mutex_lock coverage is extended to protect the if statement as well as the function call to regcache_sync(). [ Note: the lack of the regmap_lock itself is harmless for the current codec driver implementations, as snd_hdac_regmap_sync() is only for PM runtime resume that is prohibited during the codec probe. But the change makes the whole code more consistent, so it's merged as is -- tiwai ] Reported-by: BassCheck <bass(a)buaa.edu.cn> Signed-off-by: Tuo Li <islituo(a)gmail.com> Link: https://lore.kernel.org/r/20230703031016.1184711-1-islituo@gmail.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/hda/hdac_regmap.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/sound/hda/hdac_regmap.c b/sound/hda/hdac_regmap.c index f258cb3a6895..9b1bcabd8414 100644 --- a/sound/hda/hdac_regmap.c +++ b/sound/hda/hdac_regmap.c @@ -596,10 +596,9 @@ EXPORT_SYMBOL_GPL(snd_hdac_regmap_update_raw_once); */ void snd_hdac_regmap_sync(struct hdac_device *codec) { - if (codec->regmap) { - mutex_lock(&codec->regmap_lock); + mutex_lock(&codec->regmap_lock); + if (codec->regmap) regcache_sync(codec->regmap); - mutex_unlock(&codec->regmap_lock); - } + mutex_unlock(&codec->regmap_lock); } EXPORT_SYMBOL_GPL(snd_hdac_regmap_sync); -- 2.34.1

2 1

[PATCH OLK-5.10 0/6] CVE-2024-26586
by Liu Jian 26 Feb '24

26 Feb '24

backport the fix patches from 5.10lts Amit Cohen (1): mlxsw: spectrum_acl_erp: Fix error flow of pool allocation failure Christophe JAILLET (1): mlxsw: spectrum: Use 'bitmap_zalloc()' when applicable Ido Schimmel (4): mlxsw: spectrum_acl_tcam: Add missing mutex_destroy() mlxsw: spectrum_acl_tcam: Make fini symmetric to init mlxsw: spectrum_acl_tcam: Reorder functions to avoid forward declarations mlxsw: spectrum_acl_tcam: Fix stack corruption .../mellanox/mlxsw/spectrum_acl_atcam.c | 8 +- .../mellanox/mlxsw/spectrum_acl_erp.c | 8 +- .../mellanox/mlxsw/spectrum_acl_tcam.c | 131 +++++++++--------- .../ethernet/mellanox/mlxsw/spectrum_cnt.c | 9 +- .../mellanox/mlxsw/spectrum_switchdev.c | 11 +- .../drivers/net/mlxsw/spectrum-2/tc_flower.sh | 106 +++++++++++++- 6 files changed, 187 insertions(+), 86 deletions(-) -- 2.34.1

2 7

[PATCH OLK-6.6 0/2] Remove WQ_FLAG_BOOKMARK flag
by Zizhi Wo 26 Feb '24

26 Feb '24

Fix softlockup by removing the wait_queue flag: WQ_FLAG_BOOKMARK. Matthew Wilcox (Oracle) (2): filemap: remove use of wait bookmarks sched: remove wait bookmarks include/linux/wait.h | 9 +++---- kernel/sched/wait.c | 60 ++++++++------------------------------------ mm/filemap.c | 21 +--------------- 3 files changed, 14 insertions(+), 76 deletions(-) -- 2.39.2

2 3

[PATCH OLK-5.10] mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path
by Zhengchao Shao 26 Feb '24

26 Feb '24

From: Ido Schimmel <idosch(a)nvidia.com> mainline inclusion from mainline-v6.8-rc1 commit efeb7dfea8ee10cdec11b6b6ba4e405edbe75809 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93EE7 CVE: CVE-2024-26595 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after failing to attach the region to an ACL group, we hit a NULL pointer dereference upon 'region->group->tcam' [1]. Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0 [...] Call Trace: mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fixes: 22a677661f56 ("mlxsw: spectrum: Introduce ACL core with simple TCAM implementation") Signed-off-by: Ido Schimmel <idosch(a)nvidia.com> Reviewed-by: Amit Cohen <amcohen(a)nvidia.com> Reviewed-by: Jiri Pirko <jiri(a)nvidia.com> Signed-off-by: Petr Machata <petrm(a)nvidia.com> Acked-by: Paolo Abeni <pabeni(a)redhat.com> Link: https://lore.kernel.org/r/fb6a4542bbc9fcab5a523802d97059bffbca7126.17055020… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c index 7cccc41dd69c..a7689cdd1efc 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c @@ -744,13 +744,13 @@ static void mlxsw_sp_acl_tcam_region_destroy(struct mlxsw_sp *mlxsw_sp, struct mlxsw_sp_acl_tcam_region *region) { + struct mlxsw_sp_acl_tcam *tcam = &mlxsw_sp->acl->tcam; const struct mlxsw_sp_acl_tcam_ops *ops = mlxsw_sp->acl_tcam_ops; ops->region_fini(mlxsw_sp, region->priv); mlxsw_sp_acl_tcam_region_disable(mlxsw_sp, region); mlxsw_sp_acl_tcam_region_free(mlxsw_sp, region); - mlxsw_sp_acl_tcam_region_id_put(region->group->tcam, - region->id); + mlxsw_sp_acl_tcam_region_id_put(tcam, region->id); kfree(region); } -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path
by Zhengchao Shao 26 Feb '24

26 Feb '24

From: Ido Schimmel <idosch(a)nvidia.com> mainline inclusion from mainline-v6.8-rc1 commit efeb7dfea8ee10cdec11b6b6ba4e405edbe75809 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I93EE7 CVE: CVE-2024-26595 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after failing to attach the region to an ACL group, we hit a NULL pointer dereference upon 'region->group->tcam' [1]. Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0 [...] Call Trace: mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fixes: 22a677661f56 ("mlxsw: spectrum: Introduce ACL core with simple TCAM implementation") Signed-off-by: Ido Schimmel <idosch(a)nvidia.com> Reviewed-by: Amit Cohen <amcohen(a)nvidia.com> Reviewed-by: Jiri Pirko <jiri(a)nvidia.com> Signed-off-by: Petr Machata <petrm(a)nvidia.com> Acked-by: Paolo Abeni <pabeni(a)redhat.com> Link: https://lore.kernel.org/r/fb6a4542bbc9fcab5a523802d97059bffbca7126.17055020… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c Signed-off-by: Zhengchao Shao <shaozhengchao(a)huawei.com> --- drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c index 30931a2c025b..7ce670e71a7c 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c @@ -571,12 +571,13 @@ static void mlxsw_sp_acl_tcam_region_destroy(struct mlxsw_sp *mlxsw_sp, struct mlxsw_sp_acl_tcam_region *region) { + struct mlxsw_sp_acl_tcam *tcam = &mlxsw_sp->acl->tcam; const struct mlxsw_sp_acl_tcam_ops *ops = mlxsw_sp->acl_tcam_ops; ops->region_fini(mlxsw_sp, region->priv); mlxsw_sp_acl_tcam_region_disable(mlxsw_sp, region); mlxsw_sp_acl_tcam_region_free(mlxsw_sp, region); - mlxsw_sp_acl_tcam_region_id_put(region->group->tcam, region->id); + mlxsw_sp_acl_tcam_region_id_put(tcam, region->id); mlxsw_afk_key_info_put(region->key_info); kfree(region); } -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS 14777/21632] drivers/scsi/huawei/hifc/hifc_hwif.c:517:65: sparse: sparse: incorrect type in argument 4 (different base types)
by kernel test robot 26 Feb '24

26 Feb '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: b97b63500af297c36f80416fd1f1193d227cf51a commit: 7fc993d55d1b54ae40e29dfac825a18d04d644c6 [14777/21632] scsi/hifc: add hifc driver FC service module config: x86_64-randconfig-122-20240218 (https://download.01.org/0day-ci/archive/20240226/202402261420.bgeVvnXn-lkp@…) compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240226/202402261420.bgeVvnXn-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202402261420.bgeVvnXn-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) drivers/scsi/huawei/hifc/hifc_hwif.c:27:16: sparse: sparse: cast to restricted __be32 drivers/scsi/huawei/hifc/hifc_hwif.c:32:16: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int val @@ got restricted __be32 [usertype] @@ drivers/scsi/huawei/hifc/hifc_hwif.c:32:16: sparse: expected unsigned int val drivers/scsi/huawei/hifc/hifc_hwif.c:32:16: sparse: got restricted __be32 [usertype] drivers/scsi/huawei/hifc/hifc_hwif.c:453:29: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected unsigned char [noderef] [usertype] __iomem *cfg_regs_base @@ got void *cfg_reg_base @@ drivers/scsi/huawei/hifc/hifc_hwif.c:453:29: sparse: expected unsigned char [noderef] [usertype] __iomem *cfg_regs_base drivers/scsi/huawei/hifc/hifc_hwif.c:453:29: sparse: got void *cfg_reg_base drivers/scsi/huawei/hifc/hifc_hwif.c:454:30: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected unsigned char [noderef] [usertype] __iomem *intr_regs_base @@ got void *intr_reg_base @@ drivers/scsi/huawei/hifc/hifc_hwif.c:454:30: sparse: expected unsigned char [noderef] [usertype] __iomem *intr_regs_base drivers/scsi/huawei/hifc/hifc_hwif.c:454:30: sparse: got void *intr_reg_base drivers/scsi/huawei/hifc/hifc_hwif.c:457:23: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected unsigned char [noderef] [usertype] __iomem *db_base @@ got void *db_base @@ drivers/scsi/huawei/hifc/hifc_hwif.c:457:23: sparse: expected unsigned char [noderef] [usertype] __iomem *db_base drivers/scsi/huawei/hifc/hifc_hwif.c:457:23: sparse: got void *db_base >> drivers/scsi/huawei/hifc/hifc_hwif.c:517:65: sparse: sparse: incorrect type in argument 4 (different base types) @@ expected restricted gfp_t [usertype] flag @@ got unsigned int flag @@ drivers/scsi/huawei/hifc/hifc_hwif.c:517:65: sparse: expected restricted gfp_t [usertype] flag drivers/scsi/huawei/hifc/hifc_hwif.c:517:65: sparse: got unsigned int flag drivers/scsi/huawei/hifc/hifc_hwif.c:532:65: sparse: sparse: incorrect type in argument 4 (different base types) @@ expected restricted gfp_t [usertype] flag @@ got unsigned int flag @@ drivers/scsi/huawei/hifc/hifc_hwif.c:532:65: sparse: expected restricted gfp_t [usertype] flag drivers/scsi/huawei/hifc/hifc_hwif.c:532:65: sparse: got unsigned int flag In file included from drivers/scsi/huawei/hifc/hifc_hwif.c:14: In file included from drivers/scsi/huawei/hifc/hifc_knl_adp.h:30: In file included from include/scsi/scsi_host.h:12: In file included from include/linux/blk-mq.h:5: In file included from include/linux/blkdev.h:16: include/linux/pagemap.h:425:21: warning: cast from 'int (*)(struct file *, struct page *)' to 'filler_t *' (aka 'int (*)(void *, struct page *)') converts to incompatible function type [-Wcast-function-type-strict] 425 | filler_t *filler = (filler_t *)mapping->a_ops->readpage; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 warning generated. drivers/scsi/huawei/hifc/hifc_hwif.c:442: warning: Function parameter or member 'intr_reg_base' not described in 'hifc_init_hwif' drivers/scsi/huawei/hifc/hifc_hwif.c:442: warning: Function parameter or member 'db_base_phy' not described in 'hifc_init_hwif' drivers/scsi/huawei/hifc/hifc_hwif.c:442: warning: Function parameter or member 'db_base' not described in 'hifc_init_hwif' drivers/scsi/huawei/hifc/hifc_hwif.c:442: warning: Function parameter or member 'dwqe_mapping' not described in 'hifc_init_hwif' vim +517 drivers/scsi/huawei/hifc/hifc_hwif.c 218105be120513 Chenguangli 2020-11-16 508 218105be120513 Chenguangli 2020-11-16 509 int hifc_dma_zalloc_coherent_align(void *dev_hdl, u64 size, u64 align, 218105be120513 Chenguangli 2020-11-16 510 unsigned flag, 218105be120513 Chenguangli 2020-11-16 511 struct hifc_dma_addr_align *mem_align) 218105be120513 Chenguangli 2020-11-16 512 { 218105be120513 Chenguangli 2020-11-16 513 void *vaddr, *align_vaddr; 218105be120513 Chenguangli 2020-11-16 514 dma_addr_t paddr, align_paddr; 218105be120513 Chenguangli 2020-11-16 515 u64 real_size = size; 218105be120513 Chenguangli 2020-11-16 516 218105be120513 Chenguangli 2020-11-16 @517 vaddr = dma_zalloc_coherent(dev_hdl, real_size, &paddr, flag); 218105be120513 Chenguangli 2020-11-16 518 if (!vaddr) 218105be120513 Chenguangli 2020-11-16 519 return -ENOMEM; 218105be120513 Chenguangli 2020-11-16 520 218105be120513 Chenguangli 2020-11-16 521 align_paddr = ALIGN(paddr, align); 218105be120513 Chenguangli 2020-11-16 522 /* align */ 218105be120513 Chenguangli 2020-11-16 523 if (align_paddr == paddr) { 218105be120513 Chenguangli 2020-11-16 524 align_vaddr = vaddr; 218105be120513 Chenguangli 2020-11-16 525 goto out; 218105be120513 Chenguangli 2020-11-16 526 } 218105be120513 Chenguangli 2020-11-16 527 218105be120513 Chenguangli 2020-11-16 528 dma_free_coherent(dev_hdl, real_size, vaddr, paddr); 218105be120513 Chenguangli 2020-11-16 529 218105be120513 Chenguangli 2020-11-16 530 /* realloc memory for align */ 218105be120513 Chenguangli 2020-11-16 531 real_size = size + align; 218105be120513 Chenguangli 2020-11-16 532 vaddr = dma_zalloc_coherent(dev_hdl, real_size, &paddr, flag); 218105be120513 Chenguangli 2020-11-16 533 if (!vaddr) 218105be120513 Chenguangli 2020-11-16 534 return -ENOMEM; 218105be120513 Chenguangli 2020-11-16 535 218105be120513 Chenguangli 2020-11-16 536 align_paddr = ALIGN(paddr, align); 218105be120513 Chenguangli 2020-11-16 537 align_vaddr = (void *)((u64)vaddr + (align_paddr - paddr)); 218105be120513 Chenguangli 2020-11-16 538 218105be120513 Chenguangli 2020-11-16 539 out: 218105be120513 Chenguangli 2020-11-16 540 mem_align->real_size = (u32)real_size; 218105be120513 Chenguangli 2020-11-16 541 mem_align->ori_vaddr = vaddr; 218105be120513 Chenguangli 2020-11-16 542 mem_align->ori_paddr = paddr; 218105be120513 Chenguangli 2020-11-16 543 mem_align->align_vaddr = align_vaddr; 218105be120513 Chenguangli 2020-11-16 544 mem_align->align_paddr = align_paddr; 218105be120513 Chenguangli 2020-11-16 545 218105be120513 Chenguangli 2020-11-16 546 return 0; 218105be120513 Chenguangli 2020-11-16 547 } 218105be120513 Chenguangli 2020-11-16 548 :::::: The code at line 517 was first introduced by commit :::::: 218105be120513109ae9ea5418c10586913274d4 scsi/hifc: add hifc driver chip resource module :::::: TO: Chenguangli <chenguangli2(a)huawei.com> :::::: CC: Yang Yingliang <yangyingliang(a)huawei.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH openEuler-1.0-LTS] mlxsw: spectrum_acl_tcam: Fix stack corruption
by Liu Jian 26 Feb '24

26 Feb '24

From: Ido Schimmel <idosch(a)nvidia.com> mainline inclusion from mainline-v6.8-rc1 commit 483ae90d8f976f8339cf81066312e1329f2d3706 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I932WD CVE: CVE-2024-26586 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- When tc filters are first added to a net device, the corresponding local port gets bound to an ACL group in the device. The group contains a list of ACLs. In turn, each ACL points to a different TCAM region where the filters are stored. During forwarding, the ACLs are sequentially evaluated until a match is found. One reason to place filters in different regions is when they are added with decreasing priorities and in an alternating order so that two consecutive filters can never fit in the same region because of their key usage. In Spectrum-2 and newer ASICs the firmware started to report that the maximum number of ACLs in a group is more than 16, but the layout of the register that configures ACL groups (PAGT) was not updated to account for that. It is therefore possible to hit stack corruption [1] in the rare case where more than 16 ACLs in a group are required. Fix by limiting the maximum ACL group size to the minimum between what the firmware reports and the maximum ACLs that fit in the PAGT register. Add a test case to make sure the machine does not crash when this condition is hit. [1] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fixes: c3ab435466d5 ("mlxsw: spectrum: Extend to support Spectrum-2 ASIC") Reported-by: Orel Hagag <orelh(a)nvidia.com> Signed-off-by: Ido Schimmel <idosch(a)nvidia.com> Reviewed-by: Amit Cohen <amcohen(a)nvidia.com> Signed-off-by: Petr Machata <petrm(a)nvidia.com> Acked-by: Paolo Abeni <pabeni(a)redhat.com> Link: https://lore.kernel.org/r/2d91c89afba59c22587b444994ae419dbea8d876.17055020… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> Conflicts: drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c tools/testing/selftests/drivers/net/mlxsw/spectrum-2/tc_flower.sh --- .../mellanox/mlxsw/spectrum_acl_tcam.c | 2 + .../drivers/net/mlxsw/spectrum-2/tc_flower.sh | 56 ++++++++++++++++++- 2 files changed, 57 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c index 30931a2c025b..d4ddea426939 100644 --- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c +++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c @@ -57,6 +57,8 @@ int mlxsw_sp_acl_tcam_init(struct mlxsw_sp *mlxsw_sp, tcam->max_groups = max_groups; tcam->max_group_size = MLXSW_CORE_RES_GET(mlxsw_sp->core, ACL_MAX_GROUP_SIZE); + tcam->max_group_size = min_t(unsigned int, tcam->max_group_size, + MLXSW_REG_PAGT_ACL_MAX_NUM); err = ops->init(mlxsw_sp, tcam->priv, tcam); if (err) diff --git a/tools/testing/selftests/drivers/net/mlxsw/spectrum-2/tc_flower.sh b/tools/testing/selftests/drivers/net/mlxsw/spectrum-2/tc_flower.sh index 3b75180f455d..61f0ce8454e0 100755 --- a/tools/testing/selftests/drivers/net/mlxsw/spectrum-2/tc_flower.sh +++ b/tools/testing/selftests/drivers/net/mlxsw/spectrum-2/tc_flower.sh @@ -8,7 +8,7 @@ lib_dir=$(dirname $0)/../../../../net/forwarding ALL_TESTS="single_mask_test identical_filters_test two_masks_test \ - multiple_masks_test ctcam_edge_cases_test" + multiple_masks_test ctcam_edge_cases_test max_group_size_test" NUM_NETIFS=2 source $lib_dir/tc_common.sh source $lib_dir/lib.sh @@ -324,6 +324,60 @@ ctcam_edge_cases_test() ctcam_no_atcam_masks_test } +max_group_size_test() +{ + # The number of ACLs in an ACL group is limited. Once the maximum + # number of ACLs has been reached, filters cannot be added. This test + # verifies that when this limit is reached, insertion fails without + # crashing. + + RET=0 + + local num_acls=32 + local max_size + local ret + + if [[ "$tcflags" != "skip_sw" ]]; then + return 0; + fi + + for ((i=1; i < $num_acls; i++)); do + if [[ $(( i % 2 )) == 1 ]]; then + tc filter add dev $h2 ingress pref $i proto ipv4 \ + flower $tcflags dst_ip 198.51.100.1/32 \ + ip_proto tcp tcp_flags 0x01/0x01 \ + action drop &> /dev/null + else + tc filter add dev $h2 ingress pref $i proto ipv6 \ + flower $tcflags dst_ip 2001:db8:1::1/128 \ + action drop &> /dev/null + fi + + ret=$? + [[ $ret -ne 0 ]] && max_size=$((i - 1)) && break + done + + # We expect to exceed the maximum number of ACLs in a group, so that + # insertion eventually fails. Otherwise, the test should be adjusted to + # add more filters. + check_fail $ret "expected to exceed number of ACLs in a group" + + for ((; i >= 1; i--)); do + if [[ $(( i % 2 )) == 1 ]]; then + tc filter del dev $h2 ingress pref $i proto ipv4 \ + flower $tcflags dst_ip 198.51.100.1/32 \ + ip_proto tcp tcp_flags 0x01/0x01 \ + action drop &> /dev/null + else + tc filter del dev $h2 ingress pref $i proto ipv6 \ + flower $tcflags dst_ip 2001:db8:1::1/128 \ + action drop &> /dev/null + fi + done + + log_test "max ACL group size test ($tcflags). max size $max_size" +} + setup_prepare() { h1=${NETIFS[p1]} -- 2.34.1

2 1

[PATCH openEuler-22.03-LTS 0/1] backport patch to fix CVE vulnerabilities from olk-6.6
by Yuntao Liu 26 Feb '24

26 Feb '24

patch to fix CVE-2024-23196. Tuo Li (1): ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync() sound/hda/hdac_regmap.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS v3 0/2] CVE-2023-52435
by Ziyang Xuan 26 Feb '24

26 Feb '24

v3: - Add fixes tag for patch 2. v2: - Fix comment head of patch 1. - Fix compile warning of patch 1. Eric Dumazet (1): net: prevent mss overflow in skb_segment() Ziyang Xuan (1): net: Fix compile warning in skb_segment() net/core/skbuff.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 2.25.1

2 3

[PATCH OLK-6.6] kvm: kabi: KABI reservation for RME
by Guangwei Zhou 26 Feb '24

26 Feb '24

driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I92TT5 CVE: NA ---------------------------------------------------------------------- Reserve KABI for struct kvm_arch and struct kvm_vcpu_arch for ARMv9 RME feature. Signed-off-by: Guangwei Zhou <zhouguangwei5(a)huawei.com> --- arch/arm64/include/asm/kvm_host.h | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index 993b60d7219d..7c34e0b0b875 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -27,6 +27,7 @@ #include <asm/fpsimd.h> #include <asm/kvm.h> #include <asm/kvm_asm.h> +#include <linux/kabi.h> #define __KVM_HAVE_ARCH_INTC_INITIALIZED @@ -286,6 +287,15 @@ struct kvm_arch { cpumask_var_t sched_cpus; /* Union of all vcpu's cpus_ptr */ u64 tlbi_dvmbm; #endif + + KABI_RESERVE(1) + KABI_RESERVE(2) + KABI_RESERVE(3) + KABI_RESERVE(4) + KABI_RESERVE(5) + KABI_RESERVE(6) + KABI_RESERVE(7) + KABI_RESERVE(8) }; struct kvm_vcpu_fault_info { @@ -604,6 +614,26 @@ struct kvm_vcpu_arch { cpumask_var_t sched_cpus; cpumask_var_t pre_sched_cpus; #endif + + KABI_RESERVE(1) + KABI_RESERVE(2) + KABI_RESERVE(3) + KABI_RESERVE(4) + KABI_RESERVE(5) + KABI_RESERVE(6) + KABI_RESERVE(7) + KABI_RESERVE(8) + KABI_RESERVE(9) + KABI_RESERVE(10) + KABI_RESERVE(11) + KABI_RESERVE(12) + KABI_RESERVE(13) + KABI_RESERVE(14) + KABI_RESERVE(15) + KABI_RESERVE(16) + KABI_RESERVE(17) + KABI_RESERVE(18) + KABI_RESERVE(19) }; /* -- 2.33.0

2 1

[PATCH OLK-6.6] f2fs: fix to avoid dirent corruption
by Zizhi Wo 26 Feb '24

26 Feb '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v6.6.14 commit d3c0b49aaa12a61d560528f5d605029ab57f0728 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I932VP CVE: CVE-2023-52444 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 53edb549565f55ccd0bdf43be3d66ce4c2d48b28 ] As Al reported in link[1]: f2fs_rename() ... if (old_dir != new_dir && !whiteout) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); else f2fs_put_page(old_dir_page, 0); You want correct inumber in the ".." link. And cross-directory rename does move the source to new parent, even if you'd been asked to leave a whiteout in the old place. [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ With below testcase, it may cause dirent corruption, due to it missed to call f2fs_set_link() to update ".." link to new directory. - mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421) --> Bad inode number[0x4] for '..', parent parent ino is [0x3] [FSCK] other corrupted bugs [Fail] Fixes: 7e01e7ad746b ("f2fs: support RENAME_WHITEOUT") Cc: Jan Kara <jack(a)suse.cz> Reported-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Chao Yu <chao(a)kernel.org> Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/f2fs/namei.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c index 193b22a2d6bf..02d9c47797be 100644 --- a/fs/f2fs/namei.c +++ b/fs/f2fs/namei.c @@ -1106,7 +1106,7 @@ static int f2fs_rename(struct mnt_idmap *idmap, struct inode *old_dir, } if (old_dir_entry) { - if (old_dir != new_dir && !whiteout) + if (old_dir != new_dir) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); else -- 2.39.2

2 1

[PATCH OLK-5.10] f2fs: fix to avoid dirent corruption
by Zizhi Wo 26 Feb '24

26 Feb '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v5.10.209 commit 6f866885e147d33efc497f1095f35b2ee5ec7310 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I932VP CVE: CVE-2023-52444 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 53edb549565f55ccd0bdf43be3d66ce4c2d48b28 ] As Al reported in link[1]: f2fs_rename() ... if (old_dir != new_dir && !whiteout) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); else f2fs_put_page(old_dir_page, 0); You want correct inumber in the ".." link. And cross-directory rename does move the source to new parent, even if you'd been asked to leave a whiteout in the old place. [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ With below testcase, it may cause dirent corruption, due to it missed to call f2fs_set_link() to update ".." link to new directory. - mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421) --> Bad inode number[0x4] for '..', parent parent ino is [0x3] [FSCK] other corrupted bugs [Fail] Fixes: 7e01e7ad746b ("f2fs: support RENAME_WHITEOUT") Cc: Jan Kara <jack(a)suse.cz> Reported-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Chao Yu <chao(a)kernel.org> Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/f2fs/namei.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c index 72b109685db4..99e4ec48d2a4 100644 --- a/fs/f2fs/namei.c +++ b/fs/f2fs/namei.c @@ -1066,7 +1066,7 @@ static int f2fs_rename(struct inode *old_dir, struct dentry *old_dentry, } if (old_dir_entry) { - if (old_dir != new_dir && !whiteout) + if (old_dir != new_dir) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); else -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS] f2fs: fix to avoid dirent corruption
by Zizhi Wo 26 Feb '24

26 Feb '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v4.19.306 commit 02160112e6d45c2610b049df6eb693d7a2e57b46 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I932VP CVE: CVE-2023-52444 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 53edb549565f55ccd0bdf43be3d66ce4c2d48b28 ] As Al reported in link[1]: f2fs_rename() ... if (old_dir != new_dir && !whiteout) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); else f2fs_put_page(old_dir_page, 0); You want correct inumber in the ".." link. And cross-directory rename does move the source to new parent, even if you'd been asked to leave a whiteout in the old place. [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ With below testcase, it may cause dirent corruption, due to it missed to call f2fs_set_link() to update ".." link to new directory. - mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421) --> Bad inode number[0x4] for '..', parent parent ino is [0x3] [FSCK] other corrupted bugs [Fail] Fixes: 7e01e7ad746b ("f2fs: support RENAME_WHITEOUT") Cc: Jan Kara <jack(a)suse.cz> Reported-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Chao Yu <chao(a)kernel.org> Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/f2fs/namei.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c index 0ace2c2e3de9..98afafe633a2 100644 --- a/fs/f2fs/namei.c +++ b/fs/f2fs/namei.c @@ -968,7 +968,7 @@ static int f2fs_rename(struct inode *old_dir, struct dentry *old_dentry, } if (old_dir_entry) { - if (old_dir != new_dir && !whiteout) + if (old_dir != new_dir) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); else -- 2.39.2

2 1

[openEuler-1.0-LTS] f2fs: fix to avoid dirent corruption
by Zizhi Wo 26 Feb '24

26 Feb '24

From: Chao Yu <chao(a)kernel.org> stable inclusion from stable-v4.19.306 commit 02160112e6d45c2610b049df6eb693d7a2e57b46 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I932VP CVE: CVE-2023-52444 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 53edb549565f55ccd0bdf43be3d66ce4c2d48b28 ] As Al reported in link[1]: f2fs_rename() ... if (old_dir != new_dir && !whiteout) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); else f2fs_put_page(old_dir_page, 0); You want correct inumber in the ".." link. And cross-directory rename does move the source to new parent, even if you'd been asked to leave a whiteout in the old place. [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ With below testcase, it may cause dirent corruption, due to it missed to call f2fs_set_link() to update ".." link to new directory. - mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421) --> Bad inode number[0x4] for '..', parent parent ino is [0x3] [FSCK] other corrupted bugs [Fail] Fixes: 7e01e7ad746b ("f2fs: support RENAME_WHITEOUT") Cc: Jan Kara <jack(a)suse.cz> Reported-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Chao Yu <chao(a)kernel.org> Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/f2fs/namei.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c index 0ace2c2e3de9..98afafe633a2 100644 --- a/fs/f2fs/namei.c +++ b/fs/f2fs/namei.c @@ -968,7 +968,7 @@ static int f2fs_rename(struct inode *old_dir, struct dentry *old_dentry, } if (old_dir_entry) { - if (old_dir != new_dir && !whiteout) + if (old_dir != new_dir) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); else -- 2.39.2

1 0

[openeuler:openEuler-1.0-LTS 13425/21632] drivers/net/ethernet/huawei/hinic/hinic_hwif.c:649:65: sparse: sparse: incorrect type in argument 4 (different base types)
by kernel test robot 25 Feb '24

25 Feb '24

tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: b97b63500af297c36f80416fd1f1193d227cf51a commit: 90f09a01314abe26de1a722d1b51c351d84e1f5b [13425/21632] net/hinic: Add support for X86 Arch config: x86_64-randconfig-122-20240218 (https://download.01.org/0day-ci/archive/20240225/202402252031.ls64imy6-lkp@…) compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240225/202402252031.ls64imy6-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202402252031.ls64imy6-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) drivers/net/ethernet/huawei/hinic/hinic_hwif.c:40:16: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/huawei/hinic/hinic_hwif.c:46:16: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int val @@ got restricted __be32 [usertype] @@ drivers/net/ethernet/huawei/hinic/hinic_hwif.c:46:16: sparse: expected unsigned int val drivers/net/ethernet/huawei/hinic/hinic_hwif.c:46:16: sparse: got restricted __be32 [usertype] drivers/net/ethernet/huawei/hinic/hinic_hwif.c:575:29: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected unsigned char [noderef] [usertype] __iomem *cfg_regs_base @@ got void *cfg_reg_base @@ drivers/net/ethernet/huawei/hinic/hinic_hwif.c:575:29: sparse: expected unsigned char [noderef] [usertype] __iomem *cfg_regs_base drivers/net/ethernet/huawei/hinic/hinic_hwif.c:575:29: sparse: got void *cfg_reg_base drivers/net/ethernet/huawei/hinic/hinic_hwif.c:576:30: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected unsigned char [noderef] [usertype] __iomem *intr_regs_base @@ got void *intr_reg_base @@ drivers/net/ethernet/huawei/hinic/hinic_hwif.c:576:30: sparse: expected unsigned char [noderef] [usertype] __iomem *intr_regs_base drivers/net/ethernet/huawei/hinic/hinic_hwif.c:576:30: sparse: got void *intr_reg_base drivers/net/ethernet/huawei/hinic/hinic_hwif.c:579:23: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected unsigned char [noderef] [usertype] __iomem *db_base @@ got void *db_base @@ drivers/net/ethernet/huawei/hinic/hinic_hwif.c:579:23: sparse: expected unsigned char [noderef] [usertype] __iomem *db_base drivers/net/ethernet/huawei/hinic/hinic_hwif.c:579:23: sparse: got void *db_base >> drivers/net/ethernet/huawei/hinic/hinic_hwif.c:649:65: sparse: sparse: incorrect type in argument 4 (different base types) @@ expected restricted gfp_t [usertype] flag @@ got unsigned int flag @@ drivers/net/ethernet/huawei/hinic/hinic_hwif.c:649:65: sparse: expected restricted gfp_t [usertype] flag drivers/net/ethernet/huawei/hinic/hinic_hwif.c:649:65: sparse: got unsigned int flag drivers/net/ethernet/huawei/hinic/hinic_hwif.c:664:65: sparse: sparse: incorrect type in argument 4 (different base types) @@ expected restricted gfp_t [usertype] flag @@ got unsigned int flag @@ drivers/net/ethernet/huawei/hinic/hinic_hwif.c:664:65: sparse: expected restricted gfp_t [usertype] flag drivers/net/ethernet/huawei/hinic/hinic_hwif.c:664:65: sparse: got unsigned int flag drivers/net/ethernet/huawei/hinic/hinic_hwif.c:970:17: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/huawei/hinic/hinic_hwif.c:979:17: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/huawei/hinic/hinic_hwif.c:564: warning: Function parameter or member 'intr_reg_base' not described in 'hinic_init_hwif' drivers/net/ethernet/huawei/hinic/hinic_hwif.c:564: warning: Function parameter or member 'db_base_phy' not described in 'hinic_init_hwif' drivers/net/ethernet/huawei/hinic/hinic_hwif.c:564: warning: Function parameter or member 'db_base' not described in 'hinic_init_hwif' drivers/net/ethernet/huawei/hinic/hinic_hwif.c:564: warning: Function parameter or member 'dwqe_mapping' not described in 'hinic_init_hwif' vim +649 drivers/net/ethernet/huawei/hinic/hinic_hwif.c 746ea35981b1f7 Xue 2019-01-30 640 746ea35981b1f7 Xue 2019-01-30 641 int hinic_dma_zalloc_coherent_align(void *dev_hdl, u64 size, u64 align, 746ea35981b1f7 Xue 2019-01-30 642 unsigned int flag, 746ea35981b1f7 Xue 2019-01-30 643 struct hinic_dma_addr_align *mem_align) 746ea35981b1f7 Xue 2019-01-30 644 { 746ea35981b1f7 Xue 2019-01-30 645 void *vaddr, *align_vaddr; 746ea35981b1f7 Xue 2019-01-30 646 dma_addr_t paddr, align_paddr; 746ea35981b1f7 Xue 2019-01-30 647 u64 real_size = size; 746ea35981b1f7 Xue 2019-01-30 648 746ea35981b1f7 Xue 2019-01-30 @649 vaddr = dma_zalloc_coherent(dev_hdl, real_size, &paddr, flag); 746ea35981b1f7 Xue 2019-01-30 650 if (!vaddr) 746ea35981b1f7 Xue 2019-01-30 651 return -ENOMEM; 746ea35981b1f7 Xue 2019-01-30 652 746ea35981b1f7 Xue 2019-01-30 653 align_paddr = ALIGN(paddr, align); 746ea35981b1f7 Xue 2019-01-30 654 /* align */ 746ea35981b1f7 Xue 2019-01-30 655 if (align_paddr == paddr) { 746ea35981b1f7 Xue 2019-01-30 656 align_vaddr = vaddr; 746ea35981b1f7 Xue 2019-01-30 657 goto out; 746ea35981b1f7 Xue 2019-01-30 658 } 746ea35981b1f7 Xue 2019-01-30 659 746ea35981b1f7 Xue 2019-01-30 660 dma_free_coherent(dev_hdl, real_size, vaddr, paddr); 746ea35981b1f7 Xue 2019-01-30 661 746ea35981b1f7 Xue 2019-01-30 662 /* realloc memory for align */ 746ea35981b1f7 Xue 2019-01-30 663 real_size = size + align; 746ea35981b1f7 Xue 2019-01-30 664 vaddr = dma_zalloc_coherent(dev_hdl, real_size, &paddr, flag); 746ea35981b1f7 Xue 2019-01-30 665 if (!vaddr) 746ea35981b1f7 Xue 2019-01-30 666 return -ENOMEM; 746ea35981b1f7 Xue 2019-01-30 667 746ea35981b1f7 Xue 2019-01-30 668 align_paddr = ALIGN(paddr, align); 746ea35981b1f7 Xue 2019-01-30 669 align_vaddr = (void *)((u64)vaddr + (align_paddr - paddr)); 746ea35981b1f7 Xue 2019-01-30 670 746ea35981b1f7 Xue 2019-01-30 671 out: 746ea35981b1f7 Xue 2019-01-30 672 mem_align->real_size = (u32)real_size; 746ea35981b1f7 Xue 2019-01-30 673 mem_align->ori_vaddr = vaddr; 746ea35981b1f7 Xue 2019-01-30 674 mem_align->ori_paddr = paddr; 746ea35981b1f7 Xue 2019-01-30 675 mem_align->align_vaddr = align_vaddr; 746ea35981b1f7 Xue 2019-01-30 676 mem_align->align_paddr = align_paddr; 746ea35981b1f7 Xue 2019-01-30 677 746ea35981b1f7 Xue 2019-01-30 678 return 0; 746ea35981b1f7 Xue 2019-01-30 679 } 746ea35981b1f7 Xue 2019-01-30 680 :::::: The code at line 649 was first introduced by commit :::::: 746ea35981b1f77e988d48642409d73f0470b3eb net: hinic: Add Hardware Abstract Layer :::::: TO: Xue <xuechaojing(a)huawei.com> :::::: CC: Xie XiuQi <xiexiuqi(a)huawei.com> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0