- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode()
by Liu Mingrui 26 Jul '25

26 Jul '25

From: Suzuki K Poulose <suzuki.poulose(a)arm.com> stable inclusion from stable-v6.6.89 commit 2f2803e4b5e4df2b08d378deaab78b1681ef9b30 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC6BH2 CVE: CVE-2025-37819 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 3318dc299b072a0511d6dfd8367f3304fb6d9827 upstream. With ACPI in place, gicv2m_get_fwnode() is registered with the pci subsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtime during a PCI host bridge probe. But, the call back is wrongly marked as __init, causing it to be freed, while being registered with the PCI subsystem and could trigger: Unable to handle kernel paging request at virtual address ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (P) pci_set_bus_msi_domain+0x74/0x88 pci_register_host_bridge+0x194/0x548 This is easily reproducible on a Juno board with ACPI boot. Retain the function for later use. Fixes: 0644b3daca28 ("irqchip/gic-v2m: acpi: Introducing GICv2m ACPI support") Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Reviewed-by: Marc Zyngier <maz(a)kernel.org> Cc: stable(a)vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Liu Mingrui <liumingrui(a)huawei.com> --- drivers/irqchip/irq-gic-v2m.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic-v2m.c b/drivers/irqchip/irq-gic-v2m.c index d83c2c85962c..683e8721e3b4 100644 --- a/drivers/irqchip/irq-gic-v2m.c +++ b/drivers/irqchip/irq-gic-v2m.c @@ -454,7 +454,7 @@ static int __init gicv2m_of_init(struct fwnode_handle *parent_handle, #ifdef CONFIG_ACPI static int acpi_num_msi; -static __init struct fwnode_handle *gicv2m_get_fwnode(struct device *dev) +static struct fwnode_handle *gicv2m_get_fwnode(struct device *dev) { struct v2m_data *data; -- 2.25.1

2 1

[PATCH OLK-6.6] arm64: Fix guest app segment fault when disable_sdei_nmi_watchdog
by Jinjie Ruan 26 Jul '25

26 Jul '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/release-management/issues/IBV2E4 -------------------------------- 1650 XINT hardware feature use 32 bit irq entry to handle IRQs. When disable_sdei_nmi_watchdog is set and the XINT feature is enabled, the hardlockup watchdog will use FEAT_NMI which will be converted to XINT when trapped at EL0, the guest application segment fault occurs. KPTI and spectre_bhb update this_cpu_vector and vbar_el1, but 1650 not enable them, so vbar_el1 will be updated to xint vector "vectors_xcall_xint" when xint enabled, so the host xint has no probelm. When running VM, if a host watchdog NMI inetrrupt the guest, it will restore vbar_el1 with this_cpu_vector of this cpu, which is "vectors", so the NMI will be handled as XINT with 32bit irq entry, which cause guest application segment fault. Update the this_cpu_vector to xint vector to fix it. Fixes: 7f2e02718bba ("arm64: entry: Support hardware xcall and xint") Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- arch/arm64/kernel/cpufeature.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index b13858668877..49f047731d71 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -2503,6 +2503,7 @@ static void enable_xcall_xint_vectors(void) * the vbar_el1 from the default vectors to the xcall/xint vectors * at once. */ + __this_cpu_write(this_cpu_vector, vectors_xcall_xint); write_sysreg(vectors_xcall_xint, vbar_el1); isb(); } -- 2.34.1

2 1

[PATCH OLK-6.6] scsi: megaraid_sas: Fix invalid node index
by Liu Mingrui 26 Jul '25

26 Jul '25

From: Chen Yu <yu.c.chen(a)intel.com> mainline inclusion from mainline-v6.16 commit 752eb816b55adb0673727ba0ed96609a17895654 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICL7XM CVE: CVE-2025-38239 Reference: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm… -------------------------------- On a system with DRAM interleave enabled, out-of-bound access is detected: megaraid_sas 0000:3f:00.0: requested/available msix 128/128 poll_queue 0 ------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask *[1024]' dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_out_of_bounds.cold+0x46/0x4b megasas_alloc_irq_vectors+0x149/0x190 [megaraid_sas] megasas_probe_one.cold+0xa4d/0x189c [megaraid_sas] local_pci_probe+0x42/0x90 pci_device_probe+0xdc/0x290 really_probe+0xdb/0x340 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8b/0xe0 bus_add_driver+0x142/0x220 driver_register+0x72/0xd0 megasas_init+0xdf/0xff0 [megaraid_sas] do_one_initcall+0x57/0x310 do_init_module+0x90/0x250 init_module_from_file+0x85/0xc0 idempotent_init_module+0x114/0x310 __x64_sys_finit_module+0x65/0xc0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Fix it accordingly. Signed-off-by: Chen Yu <yu.c.chen(a)intel.com> Link: https://lore.kernel.org/r/20250604042556.3731059-1-yu.c.chen@intel.com Fixes: 8049da6f3943 ("scsi: megaraid_sas: Use irq_set_affinity_and_hint()") Cc: stable(a)vger.kernel.org Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Liu Mingrui <liumingrui(a)huawei.com> --- drivers/scsi/megaraid/megaraid_sas_base.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index 4cc93cb79b8b..aebec371a310 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -5903,7 +5903,11 @@ megasas_set_high_iops_queue_affinity_and_hint(struct megasas_instance *instance) const struct cpumask *mask; if (instance->perf_mode == MR_BALANCED_PERF_MODE) { - mask = cpumask_of_node(dev_to_node(&instance->pdev->dev)); + int nid = dev_to_node(&instance->pdev->dev); + + if (nid == NUMA_NO_NODE) + nid = 0; + mask = cpumask_of_node(nid); for (i = 0; i < instance->low_latency_index_start; i++) { irq = pci_irq_vector(instance->pdev, i); -- 2.25.1

2 1

[PATCH OLK-5.10] atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister().
by Fanhua Li 26 Jul '25

26 Jul '25

From: Kuniyuki Iwashima <kuniyu(a)google.com> mainline inclusion from mainline-v6.16-rc4 commit a433791aeaea6e84df709e0b9584b9bbe040cd1c category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICL7XV CVE: CVE-2025-38245 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- syzbot reported a warning below during atm_dev_register(). [0] Before creating a new device and procfs/sysfs for it, atm_dev_register() looks up a duplicated device by __atm_dev_lookup(). These operations are done under atm_dev_mutex. However, when removing a device in atm_dev_deregister(), it releases the mutex just after removing the device from the list that __atm_dev_lookup() iterates over. So, there will be a small race window where the device does not exist on the device list but procfs/sysfs are still not removed, triggering the splat. Let's hold the mutex until procfs/sysfs are removed in atm_dev_deregister(). [0]: proc_dir_entry 'atm/atmtcp:0' already registered WARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377 Modules linked in: CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377 Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 <0f> 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48 RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248 RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001 RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140 R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444 FS: 00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> proc_create_data+0xbe/0x110 fs/proc/generic.c:585 atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361 atm_dev_register+0x46d/0x890 net/atm/resources.c:113 atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369 atmtcp_attach drivers/atm/atmtcp.c:403 [inline] atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x115/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f38b3b74459 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459 RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005 RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0ac R13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b </TASK> Fixes: 64bf69ddff76 ("[ATM]: deregistration removes device from atm_devs list immediately") Reported-by: syzbot+8bd335d2ad3b93e80715(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/685316de.050a0220.216029.0087.GAE@google.com/ Tested-by: syzbot+8bd335d2ad3b93e80715(a)syzkaller.appspotmail.com Signed-off-by: Kuniyuki Iwashima <kuniyu(a)google.com> Link: https://patch.msgid.link/20250624214505.570679-1-kuni1840@gmail.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Fanhua Li <lifanhua5(a)huawei.com> --- net/atm/resources.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/atm/resources.c b/net/atm/resources.c index 3ad39ae97132..fb8cf4cd6c1d 100644 --- a/net/atm/resources.c +++ b/net/atm/resources.c @@ -148,11 +148,10 @@ void atm_dev_deregister(struct atm_dev *dev) */ mutex_lock(&atm_dev_mutex); list_del(&dev->dev_list); - mutex_unlock(&atm_dev_mutex); - atm_dev_release_vccs(dev); atm_unregister_sysfs(dev); atm_proc_dev_deregister(dev); + mutex_unlock(&atm_dev_mutex); atm_dev_put(dev); } -- 2.43.0

2 1

[PATCH OLK-6.6 0/2] CVE-2025-38264
by Wang Tao 26 Jul '25

26 Jul '25

*** BLURB HERE *** Hannes Reinecke (1): nvme-tcp: sanitize request list handling NeilBrown (1): llist: add interface to check if a node is on a list. drivers/nvme/host/tcp.c | 15 ++++++++++++++- include/linux/llist.h | 42 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+), 1 deletion(-) -- 2.34.1

2 3

[PATCH OLK-6.6] nfsd: nfsd4_spo_must_allow() must check this is a v4 compound request
by Li Lingfeng 26 Jul '25

26 Jul '25

From: NeilBrown <neil(a)brown.name> mainline inclusion from mainline-v6.16-rc1 commit 1244f0b2c3cecd3f349a877006e67c9492b41807 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICOXL5 CVE: CVE-2025-38430 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- If the request being processed is not a v4 compound request, then examining the cstate can have undefined results. This patch adds a check that the rpc procedure being executed (rq_procinfo) is the NFSPROC4_COMPOUND procedure. Reported-by: Olga Kornievskaia <okorniev(a)redhat.com> Cc: stable(a)vger.kernel.org Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: NeilBrown <neil(a)brown.name> Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfsd/nfs4proc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c index b3eca08f15b1..b2bbf3d6d177 100644 --- a/fs/nfsd/nfs4proc.c +++ b/fs/nfsd/nfs4proc.c @@ -3580,7 +3580,8 @@ bool nfsd4_spo_must_allow(struct svc_rqst *rqstp) struct nfs4_op_map *allow = &cstate->clp->cl_spo_must_allow; u32 opiter; - if (!cstate->minorversion) + if (rqstp->rq_procinfo != &nfsd_version4.vs_proc[NFSPROC4_COMPOUND] || + cstate->minorversion == 0) return false; if (cstate->spo_must_allowed) -- 2.46.1

2 1

[PATCH OLK-6.6 V1] sched/fair: Only increment deadline once on yield
by Wang Tao 26 Jul '25

26 Jul '25

From: Fernand Sieber <sieberf(a)amazon.com> maillist inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICITVN Reference: https://lore.kernel.org/all/20250401123622.584018-1-sieberf@amazon.com/ -------------------------------- If a task yields, the scheduler may decide to pick it again. The task in turn may decide to yield immediately or shortly after, leading to a tight loop of yields. If there's another runnable task as this point, the deadline will be increased by the slice at each loop. This can cause the deadline to runaway pretty quickly, and subsequent elevated run delays later on as the task doesn't get picked again. The reason the scheduler can pick the same task again and again despite its deadline increasing is because it may be the only eligible task at that point. Fix this by updating the deadline only to one slice ahead. Note, we might want to consider iterating on the implementation of yield as follow up: * the yielding task could be forfeiting its remaining slice by incrementing its vruntime correspondingly * in case of yield_to the yielding task could be donating its remaining slice to the target task Fixes: 147f3efaa241 ("sched/fair: Implement an EEVDF-like scheduling policy") Signed-off-by: Fernand Sieber <sieberf(a)amazon.com> Signed-off-by: Wang Tao <wangtao554(a)huawei.com> --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index c4c3afa6e7b4..e61edd3472b4 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -10336,7 +10336,7 @@ static void yield_task_fair(struct rq *rq) */ rq_clock_skip_update(rq); - se->deadline += calc_delta_fair(se->slice, se); + se->deadline = se->vruntime + calc_delta_fair(se->slice, se); } static bool yield_to_task_fair(struct rq *rq, struct task_struct *p) -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] fs/writeback: bail out if there is no more inodes for IO and queued once
by Zizhi Wo 26 Jul '25

26 Jul '25

From: Kemeng Shi <shikemeng(a)huaweicloud.com> mainline inclusion from mainline-v6.10-rc1 commit d92109891f21cf367caa2cc6dff11a4411d917f4 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICOYZ0 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- For case there is no more inodes for IO in io list from last wb_writeback, We may bail out early even there is inode in dirty list should be written back. Only bail out when we queued once to avoid missing dirtied inode. This is from code reading... Signed-off-by: Kemeng Shi <shikemeng(a)huaweicloud.com> Link: https://lore.kernel.org/r/20240228091958.288260-3-shikemeng@huaweicloud.com Fixes: aa373cf55099 ("writeback: stop background/kupdate works from livelocking other works") Reviewed-by: Jan Kara <jack(a)suse.cz> [brauner(a)kernel.org: fold in memory corruption fix from Jan in [1]] Link: https://lore.kernel.org/r/20240405132346.bid7gibby3lxxhez@quack3 [1] Signed-off-by: Christian Brauner <brauner(a)kernel.org> Conflicts: fs/fs-writeback.c [The position of spin_lock() has been adjusted, which is not related to the issue that this patch aims to fix.] Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com> --- fs/fs-writeback.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index d34054fcb702..1208f61373c8 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -1786,6 +1786,7 @@ static long wb_writeback(struct bdi_writeback *wb, struct inode *inode; long progress; struct blk_plug plug; + bool queued = false; blk_start_plug(&plug); spin_lock(&wb->list_lock); @@ -1826,8 +1827,10 @@ static long wb_writeback(struct bdi_writeback *wb, dirtied_before = jiffies; trace_writeback_start(wb, work); - if (list_empty(&wb->b_io)) + if (list_empty(&wb->b_io)) { queue_io(wb, work, dirtied_before); + queued = true; + } if (work->sb) progress = writeback_sb_inodes(work->sb, wb, work); else @@ -1844,7 +1847,7 @@ static long wb_writeback(struct bdi_writeback *wb, * mean the overall work is done. So we keep looping as long * as made some progress on cleaning pages or inodes. */ - if (progress) + if (progress || !queued) continue; /* * No more inodes for IO, bail -- 2.46.1

2 1

[PATCH OLK-6.6] fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()
by Li Lingfeng 26 Jul '25

26 Jul '25

From: Max Kellermann <max.kellermann(a)ionos.com> mainline inclusion from mainline-v6.16-rc1 commit 4c10fa44bc5f700e2ea21de2fbae520ba21f19d9 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICLHG6 CVE: CVE-2025-38338 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- Sometimes, when a file was read while it was being truncated by another NFS client, the kernel could deadlock because folio_unlock() was called twice, and the second call would XOR back the `PG_locked` flag. Most of the time (depending on the timing of the truncation), nobody notices the problem because folio_unlock() gets called three times, which flips `PG_locked` back off: 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio, nfs_return_empty_folio 2. vfs_read, nfs_read_folio, ... netfs_read_collection, netfs_unlock_abandoned_read_pages 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio, nfs_return_empty_folio The problem is that nfs_read_add_folio() is not supposed to unlock the folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is missing in nfs_return_empty_folio(). Rarely this leads to a warning in netfs_read_collection(): ------------[ cut here ]------------ R=0000031c: folio 10 is not locked WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00 [...] Workqueue: events_unbound netfs_read_collection_worker RIP: 0010:netfs_read_collection+0x7c0/0xf00 [...] Call Trace: <TASK> netfs_read_collection_worker+0x67/0x80 process_one_work+0x12e/0x2c0 worker_thread+0x295/0x3a0 Most of the time, however, processes just get stuck forever in folio_wait_bit_common(), waiting for `PG_locked` to disappear, which never happens because nobody is really holding the folio lock. Fixes: 000dbe0bec05 ("NFS: Convert buffered read paths to use netfs when fscache is enabled") Cc: stable(a)vger.kernel.org Signed-off-by: Max Kellermann <max.kellermann(a)ionos.com> Reviewed-by: Dave Wysochanski <dwysocha(a)redhat.com> Signed-off-by: Anna Schumaker <anna.schumaker(a)oracle.com> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfs/read.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/nfs/read.c b/fs/nfs/read.c index 88e6a78d37fb..ed411897e33f 100644 --- a/fs/nfs/read.c +++ b/fs/nfs/read.c @@ -56,7 +56,8 @@ static int nfs_return_empty_folio(struct folio *folio) { folio_zero_segment(folio, 0, folio_size(folio)); folio_mark_uptodate(folio); - folio_unlock(folio); + if (nfs_netfs_folio_unlock(folio)) + folio_unlock(folio); return 0; } -- 2.46.1

2 1

[PATCH OLK-5.10] jfs: add check read-only before txBeginAnon() call
by Zicheng Qu 26 Jul '25

26 Jul '25

From: Vasiliy Kovalev <kovalev(a)altlinux.org> mainline inclusion from mainline-v6.15-rc1 commit 0176e69743ecc02961f2ae1ea42439cd2bf9ed58 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC1QT9 CVE: CVE-2024-58095 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Added a read-only check before calling `txBeginAnon` in `extAlloc` and `extRecord`. This prevents modification attempts on a read-only mounted filesystem, avoiding potential errors or crashes. Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+4e89b5368baba8324e07(a)syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=4e89b5368baba8324e07 Signed-off-by: Vasiliy Kovalev <kovalev(a)altlinux.org> Signed-off-by: Dave Kleikamp <dave.kleikamp(a)oracle.com> Signed-off-by: Zicheng Qu <quzicheng(a)huawei.com> --- fs/jfs/jfs_extent.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/jfs/jfs_extent.c b/fs/jfs/jfs_extent.c index d4e063dbb9a0..d695157df567 100644 --- a/fs/jfs/jfs_extent.c +++ b/fs/jfs/jfs_extent.c @@ -77,6 +77,11 @@ extAlloc(struct inode *ip, s64 xlen, s64 pno, xad_t * xp, bool abnr) int rc; int xflag; + if (isReadOnly(ip)) { + jfs_error(ip->i_sb, "read-only filesystem\n"); + return -EIO; + } + /* This blocks if we are low on resources */ txBeginAnon(ip->i_sb); @@ -412,6 +417,11 @@ int extRecord(struct inode *ip, xad_t * xp) { int rc; + if (isReadOnly(ip)) { + jfs_error(ip->i_sb, "read-only filesystem\n"); + return -EIO; + } + txBeginAnon(ip->i_sb); mutex_lock(&JFS_IP(ip)->commit_mutex); -- 2.34.1

2 1