Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

20 participants
123736 discussions

Start a nNew thread

Tools factory from China

by decii＠pachatool.com

1 week

[PATCH] ext4: xattr: fix wrong search.here in clone_block

by Jinchao Wang

syzbot reported a KASAN out-of-bounds Read in ext4_xattr_set_entry()[1]. When xattr_find_entry() returns -ENODATA, search.here still points to the position after the last valid entry. ext4_xattr_block_set() clones the xattr block because the original block maybe shared and must not be modified in place. In the clone_block, search.here is recomputed unconditionally from the old offset, which may place it past search.first. This results in a negative reset size and an out-of-bounds memmove() in ext4_xattr_set_entry(). Fix this by initializing search.here correctly when search.not_found is set. [1] https://syzkaller.appspot.com/bug?extid=f792df426ff0f5ceb8d1 Fixes: fd48e9acdf2 (ext4: Unindent codeblock in ext4_xattr_block_set) Cc: stable(a)vger.kernel.org Reported-by: syzbot+f792df426ff0f5ceb8d1(a)syzkaller.appspotmail.com Signed-off-by: Jinchao Wang <wangjinchao600(a)gmail.com> --- fs/ext4/xattr.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c index 2e02efbddaac..cc30abeb7f30 100644 --- a/fs/ext4/xattr.c +++ b/fs/ext4/xattr.c @@ -1980,7 +1980,10 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode, goto cleanup; s->first = ENTRY(header(s->base)+1); header(s->base)->h_refcount = cpu_to_le32(1); - s->here = ENTRY(s->base + offset); + if (s->not_found) + s->here = s->first; + else + s->here = ENTRY(s->base + offset); s->end = s->base + bs->bh->b_size; /* -- 2.43.0

1 week

[PATCH 5.15.y 5.10.y] ipv4: Fix uninit-value access in __ip_make_skb()

by skulkarni＠mvista.com

From: Shigeru Yoshida <syoshida(a)redhat.com> commit fc1092f51567277509563800a3c56732070b6aa4 upstream. KMSAN reported uninit-value access in __ip_make_skb() [1]. __ip_make_skb() tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a race condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCL while __ip_make_skb() is running, the function will access icmphdr in the skb even if it is not included. This causes the issue reported by KMSAN. Check FLOWI_FLAG_KNOWN_NH on fl4->flowi4_flags instead of testing HDRINCL on the socket. Also, fl4->fl4_icmp_type and fl4->fl4_icmp_code are not initialized. These are union in struct flowi4 and are implicitly initialized by flowi4_init_output(), but we should not rely on specific union layout. Initialize these explicitly in raw_sendmsg(). [1] BUG: KMSAN: uninit-value in __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481 __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481 ip_finish_skb include/net/ip.h:243 [inline] ip_push_pending_frames+0x4c/0x5c0 net/ipv4/ip_output.c:1508 raw_sendmsg+0x2381/0x2690 net/ipv4/raw.c:654 inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x274/0x3c0 net/socket.c:745 __sys_sendto+0x62c/0x7b0 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x130/0x200 net/socket.c:2199 do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x5f6/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35a/0x7c0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] __ip_append_data+0x49ab/0x68c0 net/ipv4/ip_output.c:1128 ip_append_data+0x1e7/0x260 net/ipv4/ip_output.c:1365 raw_sendmsg+0x22b1/0x2690 net/ipv4/raw.c:648 inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x274/0x3c0 net/socket.c:745 __sys_sendto+0x62c/0x7b0 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x130/0x200 net/socket.c:2199 do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x6d/0x75 CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 Fixes: 99e5acae193e ("ipv4: Fix potential uninit variable access bug in __ip_make_skb()") Reported-by: syzkaller <syzkaller(a)googlegroups.com> Signed-off-by: Shigeru Yoshida <syoshida(a)redhat.com> Link: https://lore.kernel.org/r/20240430123945.2057348-1-syoshida@redhat.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Shubham Kulkarni <skulkarni(a)mvista.com> --- Referred stable v6.1.y version of the patch to generate this one [ v6.1 link: https://github.com/gregkh/linux/commit/55bf541e018b76b3750cb6c6ea18c46e1ac5… ] --- net/ipv4/ip_output.c | 3 ++- net/ipv4/raw.c | 3 +++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index 1e430e135aa6..70c316c0537f 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -1572,7 +1572,8 @@ struct sk_buff *__ip_make_skb(struct sock *sk, * so icmphdr does not in skb linear region and can not get icmp_type * by icmp_hdr(skb)->type. */ - if (sk->sk_type == SOCK_RAW && !inet_sk(sk)->hdrincl) + if (sk->sk_type == SOCK_RAW && + !(fl4->flowi4_flags & FLOWI_FLAG_KNOWN_NH)) icmp_type = fl4->fl4_icmp_type; else icmp_type = icmp_hdr(skb)->type; diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c index 650da4d8f7ad..5a8d5ebe6590 100644 --- a/net/ipv4/raw.c +++ b/net/ipv4/raw.c @@ -634,6 +634,9 @@ static int raw_sendmsg(struct sock *sk, struct msghdr *msg, size_t len) (hdrincl ? FLOWI_FLAG_KNOWN_NH : 0), daddr, saddr, 0, 0, sk->sk_uid); + fl4.fl4_icmp_type = 0; + fl4.fl4_icmp_code = 0; + if (!hdrincl) { rfv.msg = msg; rfv.hlen = 0; -- 2.25.1

1 week

[PATCH v2] io_uring: fix filename leak in __io_openat_prep()

by Prithvi Tambewagh

__io_openat_prep() allocates a struct filename using getname(). However, for the condition of the file being installed in the fixed file table as well as having O_CLOEXEC flag set, the function returns early. At that point, the request doesn't have REQ_F_NEED_CLEANUP flag set. Due to this, the memory for the newly allocated struct filename is not cleaned up, causing a memory leak. Fix this by setting the REQ_F_NEED_CLEANUP for the request just after the successful getname() call, so that when the request is torn down, the filename will be cleaned up, along with other resources needing cleanup. Reported-by: syzbot+00e61c43eb5e4740438f(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=00e61c43eb5e4740438f Tested-by: syzbot+00e61c43eb5e4740438f(a)syzkaller.appspotmail.com Cc: stable(a)vger.kernel.org Signed-off-by: Prithvi Tambewagh <activprithvi(a)gmail.com> --- io_uring/openclose.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/io_uring/openclose.c b/io_uring/openclose.c index bfeb91b31bba..15dde9bd6ff6 100644 --- a/io_uring/openclose.c +++ b/io_uring/openclose.c @@ -73,13 +73,13 @@ static int __io_openat_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe open->filename = NULL; return ret; } + req->flags |= REQ_F_NEED_CLEANUP; open->file_slot = READ_ONCE(sqe->file_index); if (open->file_slot && (open->how.flags & O_CLOEXEC)) return -EINVAL; open->nofile = rlimit(RLIMIT_NOFILE); - req->flags |= REQ_F_NEED_CLEANUP; if (io_openat_force_async(open)) req->flags |= REQ_F_FORCE_ASYNC; return 0; base-commit: b927546677c876e26eba308550207c2ddf812a43 -- 2.34.1

1 week

6.1 Backport request: fbf5892df21a ("kbuild: Use CRC32 and a 1MiB dictionary for XZ compressed modules")

by Christoph Biedl

Hello, please backport commit fbf5892df21a8ccfcb2fda0fd65bc3169c89ed28 Author: Martin Nybo Andersen <tweek(a)tweek.dk> Date: Fri Sep 15 12:15:39 2023 +0200 kbuild: Use CRC32 and a 1MiB dictionary for XZ compressed modules Kmod is now (since kmod commit 09c9f8c5df04 ("libkmod: Use kernel decompression when available")) using the kernel decompressor, when loading compressed modules. However, the kernel XZ decompressor is XZ Embedded, which doesn't handle CRC64 and dictionaries larger than 1MiB. Use CRC32 and 1MiB dictionary when XZ compressing and installing kernel modules. to the 6.1 stable kernel, and possibly older ones as well. The commit message actually has it all, so just my story: There's a hardware that has or had issues with never kernels (no time to check), my kernel for this board is usually static. But after building a kernel with xz-compressed modules, they wouldn't load but trigger "decompression failed with status 6". Investigation led to a CRC64 check for these files, and eventually to the above commit. The commit applies (with an offset), the resulting modules work as expected. Kernel 6.6 and newer already have that commit. Older kernels could possibly benefit from this as well, I haven't checked. Kind regards, Christoph

1 week

[PATCH] wifi: ath11k: fix qmi memory allocation logic for CALDB region

by Alexandru Gagniuc

Memory region assignment in ath11k_qmi_assign_target_mem_chunk() assumes that: 1. firmware will make a HOST_DDR_REGION_TYPE request, and 2. this request is processed before CALDB_MEM_REGION_TYPE In this case CALDB_MEM_REGION_TYPE, can safely be assigned immediately after the host region. However, if the HOST_DDR_REGION_TYPE request is not made, or the reserved-memory node is not present, then res.start and res.end are 0, and host_ddr_sz remains uninitialized. The physical address should fall back to ATH11K_QMI_CALDB_ADDRESS. That doesn't happen: resource_size(&res) returns 1 for an empty resource, and thus the if clause never takes the fallback path. ab->qmi.target_mem[idx].paddr is assigned the uninitialized value of host_ddr_sz + 0 (res.start). Use "if (res.end > res.start)" for the predicate, which correctly falls back to ATH11K_QMI_CALDB_ADDRESS. Fixes: 900730dc4705 ("wifi: ath: Use of_reserved_mem_region_to_resource() for "memory-region"") Cc: stable(a)vger.kernel.org # v6.18 Signed-off-by: Alexandru Gagniuc <mr.nuke.me(a)gmail.com> --- drivers/net/wireless/ath/ath11k/qmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath11k/qmi.c b/drivers/net/wireless/ath/ath11k/qmi.c index aea56c38bf8f3..6cc26d1c1e2a4 100644 --- a/drivers/net/wireless/ath/ath11k/qmi.c +++ b/drivers/net/wireless/ath/ath11k/qmi.c @@ -2054,7 +2054,7 @@ static int ath11k_qmi_assign_target_mem_chunk(struct ath11k_base *ab) return ret; } - if (res.end - res.start + 1 < ab->qmi.target_mem[i].size) { + if (resource_size(&res) < ab->qmi.target_mem[i].size) { ath11k_dbg(ab, ATH11K_DBG_QMI, "fail to assign memory of sz\n"); return -EINVAL; @@ -2086,7 +2086,7 @@ static int ath11k_qmi_assign_target_mem_chunk(struct ath11k_base *ab) } if (ath11k_core_coldboot_cal_support(ab)) { - if (resource_size(&res)) { + if (res.end > res.start) { ab->qmi.target_mem[idx].paddr = res.start + host_ddr_sz; ab->qmi.target_mem[idx].iaddr = -- 2.45.1

1 week

[PATCH] io_uring: fix filename leak in __io_openat_prep()

by Prithvi Tambewagh

__io_openat_prep() allocates a struct filename using getname(), but it isn't freed in case the present file is installed in the fixed file table and simultaneously, it has the flag O_CLOEXEC set in the open->how.flags field. This is an erroneous condition, since for a file installed in the fixed file table, it won't be installed in the normal file table, due to which the file cannot support close on exec. Earlier, the code just returned -EINVAL error code for this condition, however, the memory allocated for that struct filename wasn't freed, resulting in a memory leak. Hence, the case of file being installed in the fixed file table as well as having O_CLOEXEC flag in open->how.flags set, is adressed by using putname() to release the memory allocated to the struct filename, then setting the field open->filename to NULL, and after that, returning -EINVAL. Reported-by: syzbot+00e61c43eb5e4740438f(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=00e61c43eb5e4740438f Tested-by: syzbot+00e61c43eb5e4740438f(a)syzkaller.appspotmail.com Cc: stable(a)vger.kernel.org Signed-off-by: Prithvi Tambewagh <activprithvi(a)gmail.com> --- io_uring/openclose.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/io_uring/openclose.c b/io_uring/openclose.c index bfeb91b31bba..fc190a3d8112 100644 --- a/io_uring/openclose.c +++ b/io_uring/openclose.c @@ -75,8 +75,11 @@ static int __io_openat_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe } open->file_slot = READ_ONCE(sqe->file_index); - if (open->file_slot && (open->how.flags & O_CLOEXEC)) + if (open->file_slot && (open->how.flags & O_CLOEXEC)) { + putname(open->filename); + open->filename = NULL; return -EINVAL; + } open->nofile = rlimit(RLIMIT_NOFILE); req->flags |= REQ_F_NEED_CLEANUP; base-commit: b927546677c876e26eba308550207c2ddf812a43 -- 2.34.1

1 week, 1 day

[PATCH 0/4] mm/damon/sysfs: free setup failures generated zombie sub-sub dirs

by SeongJae Park

Some DAMON sysfs directory setup functions generates its sub and sub-sub directories. For example, 'monitoring_attrs/' directory setup creates 'intervals/' and 'intervals/intervals_goal/' directories under 'monitoring_attrs/' directory. When such sub-sub directories are successfully made but followup setup is failed, the setup function should recursively clean up the subdirectories. However, such setup functions are only dereferencing sub directory reference counters. As a result, under certain setup failures, the sub-sub directories keep having non-zero reference counters. It means the directories cannot be removed like zombies, and the memory for the directories cannot be freed. The user impact of this issue is limited due to the following reasons. When the issue happens, the zombie directories are still taking the path. Hence attempts to generate the directories again will fail, without additional memory leak. This means the upper bound memory leak is limited. Nonetheless this also implies controlling DAMON with a feature that requires the setup-failed sysfs files will be impossible until the system reboots. Also, the setup operations are quite simple. The certain failures would hence only rarely happen, and are difficult to artificially trigger. SeongJae Park (4): mm/damon/sysfs: cleanup intervals subdirs on attrs dir setup failure mm/damon/sysfs: cleanup attrs subdirs on context dir setup failure mm/damon/sysfs-scheme: cleanup quotas subdirs on scheme dir setup failure mm/damon/sysfs-scheme: cleanup access_pattern subdirs on scheme dir setup failure mm/damon/sysfs-schemes.c | 10 ++++++---- mm/damon/sysfs.c | 9 ++++++--- 2 files changed, 12 insertions(+), 7 deletions(-) base-commit: 6d039da6a260dd7919bebc70ebb65d250bb9c24e -- 2.47.3

1 week, 1 day

Fwd: Request to add mainline merged patch to stable kernels

by JP Dehollain

Hi Greg, thanks for looking into this.. The full commit hash is 807221d3c5ff6e3c91ff57bc82a0b7a541462e20 Note: apologies if you received this multiple times, the previous one got bounced due to html Cheers, JP ________________________________ From: Greg KH <gregkh(a)linuxfoundation.org> Sent: Tuesday, December 23, 2025 6:39:22 PM To: JP Dehollain <jpdehollain(a)gmail.com> Cc: stable(a)vger.kernel.org <stable(a)vger.kernel.org> Subject: Re: Request to add mainline merged patch to stable kernels On Tue, Dec 23, 2025 at 04:05:24PM +1100, JP Dehollain wrote: > Hello, > I recently used the patch misc: rtsx_pci: Add separate CD/WP pin > polarity reversal support with commit ID 807221d, to fix a bug causing > the cardreader driver to always load sd cards in read-only mode. > On the suggestion of the driver maintainer, I am requesting that this > patch be applied to all stable kernel versions, as it is currently > only applied to >=6.18. > Thanks, > JP > What is the git id of the commit you are looking to have backported? thanks, greg k-h

1 week, 1 day

[PATCH] ARM: dts: integrator: Fix DMA ranges mismatch warning on IM-PD1

by Kuan-Wei Chiu

When compiling the device tree for the Integrator/AP with IM-PD1, the following warning is observed regarding the display controller node: arch/arm/boot/dts/arm/integratorap-im-pd1.dts:251.3-14: Warning (dma_ranges_format): /bus@c0000000/bus@c0000000/display@1000000:dma-ranges: empty "dma-ranges" property but its #address-cells (2) differs from /bus@c0000000/bus@c0000000 (1) The display node specifies an empty "dma-ranges" property, intended to describe a 1:1 identity mapping. However, the node lacks explicit "#address-cells" and "#size-cells" properties. In this case, the device tree compiler defaults the address cells to 2 (64-bit), which conflicts with the parent bus configuration (32-bit, 1 cell). Fix this by explicitly defining "#address-cells" and "#size-cells" as 1. This matches the 32-bit architecture of the Integrator platform and ensures the address translation range is correctly parsed by the compiler. Fixes: 7bea67a99430 ("ARM: dts: integrator: Fix DMA ranges") Cc: stable(a)vger.kernel.org Signed-off-by: Kuan-Wei Chiu <visitorckw(a)gmail.com> --- arch/arm/boot/dts/arm/integratorap-im-pd1.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/arm/integratorap-im-pd1.dts b/arch/arm/boot/dts/arm/integratorap-im-pd1.dts index db13e09f2fab..6d90d9a42dc9 100644 --- a/arch/arm/boot/dts/arm/integratorap-im-pd1.dts +++ b/arch/arm/boot/dts/arm/integratorap-im-pd1.dts @@ -248,6 +248,8 @@ display@1000000 { /* 640x480 16bpp @ 25.175MHz is 36827428 bytes/s */ max-memory-bandwidth = <40000000>; memory-region = <&impd1_ram>; + #address-cells = <1>; + #size-cells = <1>; dma-ranges; port@0 { -- 2.52.0.177.g9f829587af-goog

1 week, 1 day

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror