Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

62 participants
123758 discussions

[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, 1 day

[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, 1 day

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, 1 day

[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, 1 day

[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

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, 2 days

[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, 2 days

[PATCH v1 0/3] mm: mm_cid static initialization fixes

by Mathieu Desnoyers

Hi Andrew, Here are 2 fixes for missing mm_cid fields for init_mm and efi_mm static initialization. The renaming of cpu_bitmap to flexible_array (patch 2) is needed for patch 3. Those are relevant for mainline, with CC stable. They are based on v6.19-rc2. Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Cc: linux-mm(a)kvack.org Mathieu Desnoyers (3): mm: Add missing static initializer for init_mm::mm_cid.lock mm: Rename cpu_bitmap field to flexible_array mm: Take into account mm_cid size for mm_struct static definitions drivers/firmware/efi/efi.c | 2 +- include/linux/mm_types.h | 18 +++++++++++++----- mm/init-mm.c | 5 ++++- 3 files changed, 18 insertions(+), 7 deletions(-) -- 2.39.5

1 week, 2 days

[PATCH v3] virtio: console: fix lost wakeup when device is written and polled

by Lorenz Bauer

A process issuing blocking writes to a virtio console may get stuck indefinitely if another thread polls the device. Here is how to trigger the bug: - Thread A writes to the port until the virtqueue is full. - Thread A calls wait_port_writable() and goes to sleep, waiting on port->waitqueue. - The host processes some of the write, marks buffers as used and raises an interrupt. - Before the interrupt is serviced, thread B executes port_fops_poll(). This calls reclaim_consumed_buffers() via will_write_block() and consumes all used buffers. - The interrupt is serviced. vring_interrupt() finds no used buffers via more_used() and returns without waking port->waitqueue. - Thread A is still in wait_event(port->waitqueue), waiting for a wakeup that never arrives. The crux is that invoking reclaim_consumed_buffers() may cause vring_interrupt() to omit wakeups. Fix this by calling reclaim_consumed_buffers() in out_int() before waking. This is similar to the call to discard_port_data() in in_intr() which also frees buffer from a non-sleepable context. This in turn guarantees that port->outvq_full is up to date when handling polling. Since in_intr() already populates port->inbuf we use that to avoid changing reader state. Cc: stable(a)vger.kernel.org Signed-off-by: Lorenz Bauer <lmb(a)isovalent.com> --- As far as I can tell all currently maintained stable series kernels need this commit. Applies and builds cleanly on 5.10.247, verified to fix the issue. --- Changes in v3: - Use spin_lock_irq in port_fops_poll (Arnd) - Use spin_lock in out_intr (Arnd) - Link to v2: https://lore.kernel.org/r/20251222-virtio-console-lost-wakeup-v2-1-5de93cb3… Changes in v2: - Call reclaim_consumed_buffers() in out_intr instead of issuing another wake. - Link to v1: https://lore.kernel.org/r/20251215-virtio-console-lost-wakeup-v1-1-79a5c578… --- drivers/char/virtio_console.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index 088182e54debd6029ea2c2a5542d7a28500e67b8..e6048e04c3b23d008caa2a1d31d4ac6b2841045f 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -971,10 +971,17 @@ static __poll_t port_fops_poll(struct file *filp, poll_table *wait) return EPOLLHUP; } ret = 0; - if (!will_read_block(port)) + + spin_lock_irq(&port->inbuf_lock); + if (port->inbuf) ret |= EPOLLIN | EPOLLRDNORM; - if (!will_write_block(port)) + spin_unlock_irq(&port->inbuf_lock); + + spin_lock_irq(&port->outvq_lock); + if (!port->outvq_full) ret |= EPOLLOUT; + spin_unlock_irq(&port->outvq_lock); + if (!port->host_connected) ret |= EPOLLHUP; @@ -1705,6 +1712,10 @@ static void out_intr(struct virtqueue *vq) return; } + spin_lock(&port->outvq_lock); + reclaim_consumed_buffers(port); + spin_unlock(&port->outvq_lock); + wake_up_interruptible(&port->waitqueue); } --- base-commit: d358e5254674b70f34c847715ca509e46eb81e6f change-id: 20251215-virtio-console-lost-wakeup-0f566c5cd35f Best regards, -- Lorenz Bauer <lmb(a)isovalent.com>

1 week, 2 days

[PATCH v6.1 0/2] x86/mm/pat: fix VM_PAT handling

by Ajay Kaher

[PATCH v6.1 1/2]: required to backport [PATCH v6.1 2/2]. [PATCH v6.1 2/2]: backport to fix VM_PAT handling when fork() fails in copy_page_range(). arch/x86/mm/pat/memtype.c | 50 +++++++++++++++++++++++---------------- include/linux/pgtable.h | 31 ++++++++++++++++++------ kernel/fork.c | 4 ++++ mm/memory.c | 10 ++++---- mm/mremap.c | 2 +- 5 files changed, 62 insertions(+), 35 deletions(-) -- 2.40.4

1 week, 2 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror