- Linux-stable-mirror - lists.linaro.org

[merged mm-hotfixes-stable] proc-proc_maps_open-allow-proc_mem_open-to-return-null.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: proc: proc_maps_open allow proc_mem_open to return NULL has been removed from the -mm tree. Its filename was proc-proc_maps_open-allow-proc_mem_open-to-return-null.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Jialin Wang <wjl.linux(a)gmail.com> Subject: proc: proc_maps_open allow proc_mem_open to return NULL Date: Fri, 8 Aug 2025 00:54:55 +0800 The commit 65c66047259f ("proc: fix the issue of proc_mem_open returning NULL") caused proc_maps_open() to return -ESRCH when proc_mem_open() returns NULL. This breaks legitimate /proc/<pid>/maps access for kernel threads since kernel threads have NULL mm_struct. The regression causes perf to fail and exit when profiling a kernel thread: # perf record -v -g -p $(pgrep kswapd0) ... couldn't open /proc/65/task/65/maps This patch partially reverts the commit to fix it. Link: https://lkml.kernel.org/r/20250807165455.73656-1-wjl.linux@gmail.com Fixes: 65c66047259f ("proc: fix the issue of proc_mem_open returning NULL") Signed-off-by: Jialin Wang <wjl.linux(a)gmail.com> Cc: Penglei Jiang <superman.xpt(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/task_mmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/proc/task_mmu.c~proc-proc_maps_open-allow-proc_mem_open-to-return-null +++ a/fs/proc/task_mmu.c @@ -340,8 +340,8 @@ static int proc_maps_open(struct inode * priv->inode = inode; priv->mm = proc_mem_open(inode, PTRACE_MODE_READ); - if (IS_ERR_OR_NULL(priv->mm)) { - int err = priv->mm ? PTR_ERR(priv->mm) : -ESRCH; + if (IS_ERR(priv->mm)) { + int err = PTR_ERR(priv->mm); seq_release_private(inode, file); return err; _ Patches currently in -mm which might be from wjl.linux(a)gmail.com are

2 weeks, 2 days

1
0
0 0

[merged mm-hotfixes-stable] userfaultfd-fix-a-crash-in-uffdio_move-when-pmd-is-a-migration-entry.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: userfaultfd: fix a crash in UFFDIO_MOVE when PMD is a migration entry has been removed from the -mm tree. Its filename was userfaultfd-fix-a-crash-in-uffdio_move-when-pmd-is-a-migration-entry.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Suren Baghdasaryan <surenb(a)google.com> Subject: userfaultfd: fix a crash in UFFDIO_MOVE when PMD is a migration entry Date: Wed, 6 Aug 2025 15:00:22 -0700 When UFFDIO_MOVE encounters a migration PMD entry, it proceeds with obtaining a folio and accessing it even though the entry is swp_entry_t. Add the missing check and let split_huge_pmd() handle migration entries. While at it also remove unnecessary folio check. [surenb(a)google.com: remove extra folio check, per David] Link: https://lkml.kernel.org/r/20250807200418.1963585-1-surenb@google.com Link: https://lkml.kernel.org/r/20250806220022.926763-1-surenb@google.com Fixes: adef440691ba ("userfaultfd: UFFDIO_MOVE uABI") Signed-off-by: Suren Baghdasaryan <surenb(a)google.com> Reported-by: syzbot+b446dbe27035ef6bd6c2(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68794b5c.a70a0220.693ce.0050.GAE@google.com/ Reviewed-by: Peter Xu <peterx(a)redhat.com> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: Lokesh Gidra <lokeshgidra(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/userfaultfd.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) --- a/mm/userfaultfd.c~userfaultfd-fix-a-crash-in-uffdio_move-when-pmd-is-a-migration-entry +++ a/mm/userfaultfd.c @@ -1821,13 +1821,16 @@ ssize_t move_pages(struct userfaultfd_ct /* Check if we can move the pmd without splitting it. */ if (move_splits_huge_pmd(dst_addr, src_addr, src_start + len) || !pmd_none(dst_pmdval)) { - struct folio *folio = pmd_folio(*src_pmd); + /* Can be a migration entry */ + if (pmd_present(*src_pmd)) { + struct folio *folio = pmd_folio(*src_pmd); - if (!folio || (!is_huge_zero_folio(folio) && - !PageAnonExclusive(&folio->page))) { - spin_unlock(ptl); - err = -EBUSY; - break; + if (!is_huge_zero_folio(folio) && + !PageAnonExclusive(&folio->page)) { + spin_unlock(ptl); + err = -EBUSY; + break; + } } spin_unlock(ptl); _ Patches currently in -mm which might be from surenb(a)google.com are mm-limit-the-scope-of-vma_start_read.patch mm-change-vma_start_read-to-drop-rcu-lock-on-failure.patch selftests-proc-test-procmap_query-ioctl-while-vma-is-concurrently-modified.patch fs-proc-task_mmu-factor-out-proc_maps_private-fields-used-by-procmap_query.patch fs-proc-task_mmu-execute-procmap_query-ioctl-under-per-vma-locks.patch

2 weeks, 2 days

1
0
0 0

[PATCH 6.1] Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync

by Sumanth Gavini

commit 5af1f84ed13a416297ab9ced7537f4d5ae7f329a upstream. Connections may be cleanup while waiting for the commands to complete so this attempts to check if the connection handle remains valid in case of errors that would lead to call hci_conn_failed: BUG: KASAN: slab-use-after-free in hci_conn_failed+0x1f/0x160 Read of size 8 at addr ffff888001376958 by task kworker/u3:0/52 CPU: 0 PID: 52 Comm: kworker/u3:0 Not tainted 6.5.0-rc1-00527-g2dfe76d58d3a #5615 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> dump_stack_lvl+0x1d/0x70 print_report+0xce/0x620 ? __virt_addr_valid+0xd4/0x150 ? hci_conn_failed+0x1f/0x160 kasan_report+0xd1/0x100 ? hci_conn_failed+0x1f/0x160 hci_conn_failed+0x1f/0x160 hci_abort_conn_sync+0x237/0x360 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz(a)intel.com> Signed-off-by: Sumanth Gavini <sumanth.gavini(a)yahoo.com> --- net/bluetooth/hci_sync.c | 43 +++++++++++++++++++++++++++------------- 1 file changed, 29 insertions(+), 14 deletions(-) diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c index 3f905ee4338f..acff47da799a 100644 --- a/net/bluetooth/hci_sync.c +++ b/net/bluetooth/hci_sync.c @@ -5525,31 +5525,46 @@ static int hci_reject_conn_sync(struct hci_dev *hdev, struct hci_conn *conn, int hci_abort_conn_sync(struct hci_dev *hdev, struct hci_conn *conn, u8 reason) { - int err; + int err = 0; + u16 handle = conn->handle; switch (conn->state) { case BT_CONNECTED: case BT_CONFIG: - return hci_disconnect_sync(hdev, conn, reason); + err = hci_disconnect_sync(hdev, conn, reason); + break; case BT_CONNECT: err = hci_connect_cancel_sync(hdev, conn); - /* Cleanup hci_conn object if it cannot be cancelled as it - * likelly means the controller and host stack are out of sync. - */ - if (err) { - hci_dev_lock(hdev); - hci_conn_failed(conn, err); - hci_dev_unlock(hdev); - } - return err; + break; case BT_CONNECT2: - return hci_reject_conn_sync(hdev, conn, reason); + err = hci_reject_conn_sync(hdev, conn, reason); + break; default: conn->state = BT_CLOSED; - break; + return 0; } - return 0; + /* Cleanup hci_conn object if it cannot be cancelled as it + * likelly means the controller and host stack are out of sync + * or in case of LE it was still scanning so it can be cleanup + * safely. + */ + if (err) { + struct hci_conn *c; + + /* Check if the connection hasn't been cleanup while waiting + * commands to complete. + */ + c = hci_conn_hash_lookup_handle(hdev, handle); + if (!c || c != conn) + return 0; + + hci_dev_lock(hdev); + hci_conn_failed(conn, err); + hci_dev_unlock(hdev); + } + + return err; } static int hci_disconnect_all_sync(struct hci_dev *hdev, u8 reason) -- 2.43.0

2 weeks, 2 days

2
1
0 0

[PATCH v2] net: usb: qmi_wwan: add Telit Cinterion FN990A w/audio composition

by Fabio Porcedda

Add the following Telit Cinterion FN990A w/audio composition: 0x1077: tty (diag) + adb + rmnet + audio + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (AT) T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=01 Dev#= 8 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1bc7 ProdID=1077 Rev=05.04 S: Manufacturer=Telit Wireless Solutions S: Product=FN990 S: SerialNumber=67e04c35 C: #Ifs=10 Cfg#= 1 Atr=e0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I: If#= 3 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=20 Driver=snd-usb-audio I: If#= 4 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio E: Ad=03(O) Atr=0d(Isoc) MxPS= 68 Ivl=1ms I: If#= 5 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio E: Ad=84(I) Atr=0d(Isoc) MxPS= 68 Ivl=1ms I: If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 7 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8a(I) Atr=03(Int.) MxPS= 10 Ivl=32ms I: If#= 9 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=8c(I) Atr=03(Int.) MxPS= 10 Ivl=32ms Cc: stable(a)vger.kernel.org Depends-on: ad1664fb6990 ("net: usb: qmi_wwan: fix Telit Cinterion FN990A name") Depends-on: 5728b289abbb ("net: usb: qmi_wwan: fix Telit Cinterion FE990A name") Signed-off-by: Fabio Porcedda <fabio.porcedda(a)gmail.com> Acked-by: Bjørn Mork <bjorn(a)mork.no> --- v2: - add Depends-on - add Acked-by Bjørn Mork <bjorn(a)mork.no> drivers/net/usb/qmi_wwan.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c index f5647ee0adde..e56901bb6ebc 100644 --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -1361,6 +1361,7 @@ static const struct usb_device_id products[] = { {QMI_QUIRK_SET_DTR(0x1bc7, 0x1057, 2)}, /* Telit FN980 */ {QMI_QUIRK_SET_DTR(0x1bc7, 0x1060, 2)}, /* Telit LN920 */ {QMI_QUIRK_SET_DTR(0x1bc7, 0x1070, 2)}, /* Telit FN990A */ + {QMI_QUIRK_SET_DTR(0x1bc7, 0x1077, 2)}, /* Telit FN990A w/audio */ {QMI_QUIRK_SET_DTR(0x1bc7, 0x1080, 2)}, /* Telit FE990A */ {QMI_QUIRK_SET_DTR(0x1bc7, 0x10a0, 0)}, /* Telit FN920C04 */ {QMI_QUIRK_SET_DTR(0x1bc7, 0x10a4, 0)}, /* Telit FN920C04 */ -- 2.50.1

2 weeks, 2 days

2
1
0 0

+ init-handle-bootloader-identifier-in-kernel-parameters.patch added to mm-nonmm-unstable branch

by Andrew Morton

The patch titled Subject: init: handle bootloader identifier in kernel parameters has been added to the -mm mm-nonmm-unstable branch. Its filename is init-handle-bootloader-identifier-in-kernel-parameters.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-nonmm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Huacai Chen <chenhuacai(a)loongson.cn> Subject: init: handle bootloader identifier in kernel parameters Date: Mon, 21 Jul 2025 18:13:43 +0800 BootLoader (Grub, LILO, etc) may pass an identifier such as "BOOT_IMAGE= /boot/vmlinuz-x.y.z" to kernel parameters. But these identifiers are not recognized by the kernel itself so will be passed to user space. However user space init program also doesn't recognized it. KEXEC/KDUMP (kexec-tools) may also pass an identifier such as "kexec" on some architectures. We cannot change BootLoader's behavior, because this behavior exists for many years, and there are already user space programs search BOOT_IMAGE= in /proc/cmdline to obtain the kernel image locations: https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/util.go (search getBootOptions) https://github.com/linuxdeepin/deepin-ab-recovery/blob/master/main.go (search getKernelReleaseWithBootOption) So the the best way is handle (ignore) it by the kernel itself, which can avoid such boot warnings (if we use something like init=/bin/bash, bootloader identifier can even cause a crash): Kernel command line: BOOT_IMAGE=(hd0,1)/vmlinuz-6.x root=/dev/sda3 ro console=tty Unknown kernel command line parameters "BOOT_IMAGE=(hd0,1)/vmlinuz-6.x", will be passed to user space. Link: https://lkml.kernel.org/r/20250721101343.3283480-1-chenhuacai@loongson.cn Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Jan Kara <jack(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- init/main.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/init/main.c~init-handle-bootloader-identifier-in-kernel-parameters +++ a/init/main.c @@ -544,6 +544,12 @@ static int __init unknown_bootoption(cha const char *unused, void *arg) { size_t len = strlen(param); + /* + * Well-known bootloader identifiers: + * 1. LILO/Grub pass "BOOT_IMAGE=..."; + * 2. kexec/kdump (kexec-tools) pass "kexec". + */ + const char *bootloader[] = { "BOOT_IMAGE=", "kexec", NULL }; /* Handle params aliased to sysctls */ if (sysctl_is_alias(param)) @@ -551,6 +557,12 @@ static int __init unknown_bootoption(cha repair_env_string(param, val); + /* Handle bootloader identifier */ + for (int i = 0; bootloader[i]; i++) { + if (!strncmp(param, bootloader[i], strlen(bootloader[i]))) + return 0; + } + /* Handle obsolete-style parameters */ if (obsolete_checksetup(param)) return 0; _ Patches currently in -mm which might be from chenhuacai(a)loongson.cn are init-handle-bootloader-identifier-in-kernel-parameters.patch

2 weeks, 2 days

1
0
0 0

+ mm-damon-core-fix-commit_ops_filters-by-using-correct-nth-function.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/damon/core: fix commit_ops_filters by using correct nth function has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-damon-core-fix-commit_ops_filters-by-using-correct-nth-function.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Sang-Heon Jeon <ekffu200098(a)gmail.com> Subject: mm/damon/core: fix commit_ops_filters by using correct nth function Date: Sun, 10 Aug 2025 21:42:01 +0900 damos_commit_ops_filters() incorrectly uses damos_nth_filter() which iterates core_filters. As a result, performing a commit unintentionally corrupts ops_filters. Add damos_nth_ops_filter() which iterates ops_filters. Use this function to fix issues caused by wrong iteration. Link: https://lkml.kernel.org/r/20250810124201.15743-1-ekffu200098@gmail.com Fixes: 3607cc590f18 ("mm/damon/core: support committing ops_filters") # 6.15.x Signed-off-by: Sang-Heon Jeon <ekffu200098(a)gmail.com> Reviewed-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/damon/core.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) --- a/mm/damon/core.c~mm-damon-core-fix-commit_ops_filters-by-using-correct-nth-function +++ a/mm/damon/core.c @@ -845,6 +845,18 @@ static struct damos_filter *damos_nth_fi return NULL; } +static struct damos_filter *damos_nth_ops_filter(int n, struct damos *s) +{ + struct damos_filter *filter; + int i = 0; + + damos_for_each_ops_filter(filter, s) { + if (i++ == n) + return filter; + } + return NULL; +} + static void damos_commit_filter_arg( struct damos_filter *dst, struct damos_filter *src) { @@ -908,7 +920,7 @@ static int damos_commit_ops_filters(stru int i = 0, j = 0; damos_for_each_ops_filter_safe(dst_filter, next, dst) { - src_filter = damos_nth_filter(i++, src); + src_filter = damos_nth_ops_filter(i++, src); if (src_filter) damos_commit_filter(dst_filter, src_filter); else _ Patches currently in -mm which might be from ekffu200098(a)gmail.com are mm-damon-core-fix-commit_ops_filters-by-using-correct-nth-function.patch mm-damon-update-expired-description-of-damos_action.patch docs-mm-damon-design-fix-typo-s-sz_trtied-sz_tried.patch

2 weeks, 2 days

1
0
0 0

We are interested in purchasing your products.

by PERDIS SUPER U

-- Hi, PERDIS SUPER U is a leading retail group in France with numerous outlets across the country. After reviewing your company profile and products, we’re very interested in establishing a long-term partnership. Kindly share your product catalog or website so we can review your offerings and pricing. We are ready to place orders and begin cooperation.Please note: Our payment terms are SWIFT, 14 days after delivery. Looking forward to your response. Best regards, Dominique Schelcher Director, PERDIS SUPER U RUE DE SAVOIE, 45600 SAINT-PÈRE-SUR-LOIRE VAT: FR65380071464 www.magasins-u.com

2 weeks, 2 days

1
0
0 0

+ squashfs-fix-memory-leak-in-squashfs_fill_super.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: squashfs: fix memory leak in squashfs_fill_super has been added to the -mm mm-hotfixes-unstable branch. Its filename is squashfs-fix-memory-leak-in-squashfs_fill_super.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Phillip Lougher <phillip(a)squashfs.org.uk> Subject: squashfs: fix memory leak in squashfs_fill_super Date: Mon, 11 Aug 2025 23:37:40 +0100 If sb_min_blocksize returns 0, squashfs_fill_super exits without freeing allocated memory (sb->s_fs_info). Fix this by moving the call to sb_min_blocksize to before memory is allocated. Link: https://lkml.kernel.org/r/20250811223740.110392-1-phillip@squashfs.org.uk Fixes: 734aa85390ea ("Squashfs: check return result of sb_min_blocksize") Signed-off-by: Phillip Lougher <phillip(a)squashfs.org.uk> Reported-by: Scott GUO <scottzhguo(a)tencent.com> Closes: https://lore.kernel.org/all/20250811061921.3807353-1-scott_gzh@163.com Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/squashfs/super.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) --- a/fs/squashfs/super.c~squashfs-fix-memory-leak-in-squashfs_fill_super +++ a/fs/squashfs/super.c @@ -187,10 +187,15 @@ static int squashfs_fill_super(struct su unsigned short flags; unsigned int fragments; u64 lookup_table_start, xattr_id_table_start, next_table; - int err; + int err, devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE); TRACE("Entered squashfs_fill_superblock\n"); + if (!devblksize) { + errorf(fc, "squashfs: unable to set blocksize\n"); + return -EINVAL; + } + sb->s_fs_info = kzalloc(sizeof(*msblk), GFP_KERNEL); if (sb->s_fs_info == NULL) { ERROR("Failed to allocate squashfs_sb_info\n"); @@ -201,12 +206,7 @@ static int squashfs_fill_super(struct su msblk->panic_on_errors = (opts->errors == Opt_errors_panic); - msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE); - if (!msblk->devblksize) { - errorf(fc, "squashfs: unable to set blocksize\n"); - return -EINVAL; - } - + msblk->devblksize = devblksize; msblk->devblksize_log2 = ffz(~msblk->devblksize); mutex_init(&msblk->meta_index_mutex); _ Patches currently in -mm which might be from phillip(a)squashfs.org.uk are squashfs-fix-memory-leak-in-squashfs_fill_super.patch

2 weeks, 2 days

1
0
0 0

[PATCH 0/2 v5.10] Fix CVE-2021-47498

by Shivani Agarwal

Hi, To Fix CVE-2021-47498 b4459b11e840 is required, but it has a dependency on e2118b3c3d94 ("rearrange core declarations for extended use from dm-zone.c"). Therefore backported both patches for v5.10. Thanks, Shivani Shivani Agarwal (2): dm: rearrange core declarations for extended use from dm-zone.c dm rq: don't queue request to blk-mq during DM suspend drivers/md/dm-core.h | 52 ++++++++++++++++++++++++++++++++++++++ drivers/md/dm-rq.c | 8 ++++++ drivers/md/dm.c | 59 ++++++-------------------------------------- 3 files changed, 67 insertions(+), 52 deletions(-) -- 2.40.4

2 weeks, 2 days

2
4
0 0

[PATCH v5.10] scsi: pm80xx: Fix memory leak during rmmod

by Shivani Agarwal

From: Ajish Koshy <Ajish.Koshy(a)microchip.com> [ Upstream commit 51e6ed83bb4ade7c360551fa4ae55c4eacea354b ] Driver failed to release all memory allocated. This would lead to memory leak during driver removal. Properly free memory when the module is removed. Link: https://lore.kernel.org/r/20210906170404.5682-5-Ajish.Koshy@microchip.com Acked-by: Jack Wang <jinpu.wang(a)ionos.com> Signed-off-by: Ajish Koshy <Ajish.Koshy(a)microchip.com> Signed-off-by: Viswas G <Viswas.G(a)microchip.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> [Shivani: Modified to apply on 5.10.y] Signed-off-by: Shivani Agarwal <shivani.agarwal(a)broadcom.com> --- drivers/scsi/pm8001/pm8001_init.c | 11 +++++++++++ drivers/scsi/pm8001/pm8001_sas.h | 1 + 2 files changed, 12 insertions(+) diff --git a/drivers/scsi/pm8001/pm8001_init.c b/drivers/scsi/pm8001/pm8001_init.c index f40db6f40b1d..45bffa49f876 100644 --- a/drivers/scsi/pm8001/pm8001_init.c +++ b/drivers/scsi/pm8001/pm8001_init.c @@ -1166,6 +1166,7 @@ pm8001_init_ccb_tag(struct pm8001_hba_info *pm8001_ha, struct Scsi_Host *shost, goto err_out; /* Memory region for ccb_info*/ + pm8001_ha->ccb_count = ccb_count; pm8001_ha->ccb_info = (struct pm8001_ccb_info *) kcalloc(ccb_count, sizeof(struct pm8001_ccb_info), GFP_KERNEL); if (!pm8001_ha->ccb_info) { @@ -1226,6 +1227,16 @@ static void pm8001_pci_remove(struct pci_dev *pdev) tasklet_kill(&pm8001_ha->tasklet[j]); #endif scsi_host_put(pm8001_ha->shost); + + for (i = 0; i < pm8001_ha->ccb_count; i++) { + dma_free_coherent(&pm8001_ha->pdev->dev, + sizeof(struct pm8001_prd) * PM8001_MAX_DMA_SG, + pm8001_ha->ccb_info[i].buf_prd, + pm8001_ha->ccb_info[i].ccb_dma_handle); + } + kfree(pm8001_ha->ccb_info); + kfree(pm8001_ha->devices); + pm8001_free(pm8001_ha); kfree(sha->sas_phy); kfree(sha->sas_port); diff --git a/drivers/scsi/pm8001/pm8001_sas.h b/drivers/scsi/pm8001/pm8001_sas.h index 5cd6fe6a7d2d..74099d82e436 100644 --- a/drivers/scsi/pm8001/pm8001_sas.h +++ b/drivers/scsi/pm8001/pm8001_sas.h @@ -515,6 +515,7 @@ struct pm8001_hba_info { u32 iomb_size; /* SPC and SPCV IOMB size */ struct pm8001_device *devices; struct pm8001_ccb_info *ccb_info; + u32 ccb_count; #ifdef PM8001_USE_MSIX int number_of_intr;/*will be used in remove()*/ char intr_drvname[PM8001_MAX_MSIX_VEC] -- 2.40.4

2 weeks, 2 days

4
5
0 0

[PATCH v5.10] uio_hv_generic: Fix another memory leak in error handling paths

by Shivani Agarwal

From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> commit 0b0226be3a52dadd965644bc52a807961c2c26df upstream. Memory allocated by 'vmbus_alloc_ring()' at the beginning of the probe function is never freed in the error handling path. Add the missing 'vmbus_free_ring()' call. Note that it is already freed in the .remove function. Fixes: cdfa835c6e5e ("uio_hv_generic: defer opening vmbus until first use") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Link: https://lore.kernel.org/r/0d86027b8eeed8e6360bc3d52bcdb328ff9bdca1.16205440… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [Shivani: Modified to apply on 5.10.y] Signed-off-by: Shivani Agarwal <shivani.agarwal(a)broadcom.com> --- drivers/uio/uio_hv_generic.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c index 6625d340f..865a5b289 100644 --- a/drivers/uio/uio_hv_generic.c +++ b/drivers/uio/uio_hv_generic.c @@ -306,7 +306,7 @@ hv_uio_probe(struct hv_device *dev, pdata->recv_buf = vzalloc(RECV_BUFFER_SIZE); if (pdata->recv_buf == NULL) { ret = -ENOMEM; - goto fail_close; + goto fail_free_ring; } ret = vmbus_establish_gpadl(channel, pdata->recv_buf, @@ -366,6 +366,8 @@ hv_uio_probe(struct hv_device *dev, fail_close: hv_uio_cleanup(dev, pdata); +fail_free_ring: + vmbus_free_ring(dev->channel); return ret; }

2 weeks, 2 days

2
1
0 0

[PATCH v2 0/2] iterate_folioq bug when offset==size (Was: [REGRESSION] 9pfs issues on 6.12-rc1)

by Dominique Martinet via B4 Relay

So we've had this regression in 9p for.. almost a year, which is way too long, but there was no "easy" reproducer until yesterday (thank you again!!) It turned out to be a bug with iov_iter on folios, iov_iter_get_pages_alloc2() would advance the iov_iter correctly up to the end edge of a folio and the later copy_to_iter() fails on the iterate_folioq() bug. Happy to consider alternative ways of fixing this, now there's a reproducer it's all much clearer; for the bug to be visible we basically need to make and IO with non-contiguous folios in the iov_iter which is not obvious to test with synthetic VMs, with size that triggers a zero-copy read followed by a non-zero-copy read. Signed-off-by: Dominique Martinet <asmadeus(a)codewreck.org> --- Changes in v2: - Fixed 'remain' being used uninitialized in iterate_folioq when going through the goto - s/forwarded/advanced in commit message - Link to v1: https://lore.kernel.org/r/20250811-iot_iter_folio-v1-0-d9c223adf93c@codewre… --- Dominique Martinet (2): iov_iter: iterate_folioq: fix handling of offset >= folio size iov_iter: iov_folioq_get_pages: don't leave empty slot behind include/linux/iov_iter.h | 5 ++++- lib/iov_iter.c | 6 +++--- 2 files changed, 7 insertions(+), 4 deletions(-) --- base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585 change-id: 20250811-iot_iter_folio-1b7849f88fed Best regards, -- Dominique Martinet <asmadeus(a)codewreck.org>

2 weeks, 3 days

1
1
0 0

[tip: x86/urgent] x86/fpu: Fix NULL dereference in avx512_status()

by tip-bot2 for Fushuai Wang

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 31cd31c9e17ece125aad27259501a2af69ccb020 Gitweb: https://git.kernel.org/tip/31cd31c9e17ece125aad27259501a2af69ccb020 Author: Fushuai Wang <wangfushuai(a)baidu.com> AuthorDate: Mon, 11 Aug 2025 11:50:44 -07:00 Committer: Dave Hansen <dave.hansen(a)linux.intel.com> CommitterDate: Mon, 11 Aug 2025 13:28:07 -07:00 x86/fpu: Fix NULL dereference in avx512_status() Problem ------- With CONFIG_X86_DEBUG_FPU enabled, reading /proc/[kthread]/arch_status causes a warning and a NULL pointer dereference. This is because the AVX-512 timestamp code uses x86_task_fpu() but doesn't check it for NULL. CONFIG_X86_DEBUG_FPU addles that function for kernel threads (PF_KTHREAD specifically), making it return NULL. The point of the warning was to ensure that kernel threads only access task->fpu after going through kernel_fpu_begin()/_end(). Note: all kernel tasks exposed in /proc have a valid task->fpu. Solution -------- One option is to silence the warning and check for NULL from x86_task_fpu(). However, that warning is fairly fresh and seems like a defense against misuse of the FPU state in kernel threads. Instead, stop outputting AVX-512_elapsed_ms for kernel threads altogether. The data was garbage anyway because avx512_timestamp is only updated for user threads, not kernel threads. If anyone ever wants to track kernel thread AVX-512 use, they can come back later and do it properly, separate from this bug fix. [ dhansen: mostly rewrite changelog ] Fixes: 22aafe3bcb67 ("x86/fpu: Remove init_task FPU state dependencies, add debugging warning for PF_KTHREAD tasks") Co-developed-by: Sohil Mehta <sohil.mehta(a)intel.com> Signed-off-by: Sohil Mehta <sohil.mehta(a)intel.com> Signed-off-by: Fushuai Wang <wangfushuai(a)baidu.com> Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20250811185044.2227268-1-sohil.mehta%40intel.com --- arch/x86/kernel/fpu/xstate.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c index 12ed75c..28e4fd6 100644 --- a/arch/x86/kernel/fpu/xstate.c +++ b/arch/x86/kernel/fpu/xstate.c @@ -1881,19 +1881,20 @@ long fpu_xstate_prctl(int option, unsigned long arg2) #ifdef CONFIG_PROC_PID_ARCH_STATUS /* * Report the amount of time elapsed in millisecond since last AVX512 - * use in the task. + * use in the task. Report -1 if no AVX-512 usage. */ static void avx512_status(struct seq_file *m, struct task_struct *task) { - unsigned long timestamp = READ_ONCE(x86_task_fpu(task)->avx512_timestamp); - long delta; + unsigned long timestamp; + long delta = -1; - if (!timestamp) { - /* - * Report -1 if no AVX512 usage - */ - delta = -1; - } else { + /* AVX-512 usage is not tracked for kernel threads. Don't report anything. */ + if (task->flags & (PF_KTHREAD | PF_USER_WORKER)) + return; + + timestamp = READ_ONCE(x86_task_fpu(task)->avx512_timestamp); + + if (timestamp) { delta = (long)(jiffies - timestamp); /* * Cap to LONG_MAX if time difference > LONG_MAX

2 weeks, 3 days

1
0
0 0

[PATCH] iio: imu: inv_icm42600: change invalid data error to EBUSY

by Jean-Baptiste Maneyrol via B4 Relay

From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com> Temperature sensor returns the temperature of the mechanical parts of the chip. If both accel and gyro are off, temperature sensor is also automatically turned off and return invalid data. In this case, returning EBUSY error code is better then EINVAL and indicates userspace that it needs to retry reading temperature in another context. Fixes: bc3eb0207fb5 ("iio: imu: inv_icm42600: add temperature sensor support") Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com> Cc: stable(a)vger.kernel.org --- drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c index 8b15afca498cb5dfa7e056a60d3c78e419f11b29..1756f3d07049a26038776a35d9242f3dd1320354 100644 --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c @@ -32,8 +32,12 @@ static int inv_icm42600_temp_read(struct inv_icm42600_state *st, s16 *temp) goto exit; *temp = (s16)be16_to_cpup(raw); + /* + * Temperature data is invalid if both accel and gyro are off. + * Return EBUSY in this case. + */ if (*temp == INV_ICM42600_DATA_INVALID) - ret = -EINVAL; + ret = -EBUSY; exit: mutex_unlock(&st->lock); --- base-commit: 6408dba154079656d069a6a25fb3a8954959474c change-id: 20250807-inv-icm42600-change-temperature-error-code-65d16a98c6e1 Best regards, -- Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com>

2 weeks, 3 days

4
4
0 0

[PATCH] kconfig: nconf: NUL-terminate 'line' correctly in fill_window()

by Thorsten Blum

Use 'min(len, x)' as the index instead of just 'len' to NUL-terminate the copied 'line' string at the correct position. Add a newline after the local variable declarations to silence a checkpatch warning. Cc: stable(a)vger.kernel.org Fixes: 692d97c380c6 ("kconfig: new configuration interface (nconfig)") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- scripts/kconfig/nconf.gui.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/scripts/kconfig/nconf.gui.c b/scripts/kconfig/nconf.gui.c index 7206437e784a..ec021ebd2c52 100644 --- a/scripts/kconfig/nconf.gui.c +++ b/scripts/kconfig/nconf.gui.c @@ -175,8 +175,9 @@ void fill_window(WINDOW *win, const char *text) for (i = 0; i < total_lines; i++) { char tmp[x+10]; const char *line = get_line(text, i); - int len = get_line_length(line); - strncpy(tmp, line, min(len, x)); + int len = min(get_line_length(line), x); + + strncpy(tmp, line, len); tmp[len] = '\0'; mvwprintw(win, i, 0, "%s", tmp); } -- 2.50.1

2 weeks, 3 days

3
4
0 0

[tip: locking/urgent] futex: Use user_write_access_begin/_end() in futex_put_value()

by tip-bot2 for Waiman Long

The following commit has been merged into the locking/urgent branch of tip: Commit-ID: dfb36e4a8db0cd56f92d4cb445f54e85a9b40897 Gitweb: https://git.kernel.org/tip/dfb36e4a8db0cd56f92d4cb445f54e85a9b40897 Author: Waiman Long <longman(a)redhat.com> AuthorDate: Mon, 11 Aug 2025 10:11:47 -04:00 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Mon, 11 Aug 2025 17:53:21 +02:00 futex: Use user_write_access_begin/_end() in futex_put_value() Commit cec199c5e39b ("futex: Implement FUTEX2_NUMA") introduced the futex_put_value() helper to write a value to the given user address. However, it uses user_read_access_begin() before the write. For architectures that differentiate between read and write accesses, like PowerPC, futex_put_value() fails with -EFAULT. Fix that by using the user_write_access_begin/user_write_access_end() pair instead. Fixes: cec199c5e39b ("futex: Implement FUTEX2_NUMA") Signed-off-by: Waiman Long <longman(a)redhat.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20250811141147.322261-1-longman@redhat.com --- kernel/futex/futex.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/futex/futex.h b/kernel/futex/futex.h index c74eac5..2cd5709 100644 --- a/kernel/futex/futex.h +++ b/kernel/futex/futex.h @@ -319,13 +319,13 @@ static __always_inline int futex_put_value(u32 val, u32 __user *to) { if (can_do_masked_user_access()) to = masked_user_access_begin(to); - else if (!user_read_access_begin(to, sizeof(*to))) + else if (!user_write_access_begin(to, sizeof(*to))) return -EFAULT; unsafe_put_user(val, to, Efault); - user_read_access_end(); + user_write_access_end(); return 0; Efault: - user_read_access_end(); + user_write_access_end(); return -EFAULT; }

2 weeks, 3 days

1
0
0 0

[PATCH vulns 0/1] change the sha1 for CVE-2024-26661

by Qingfeng Hao

There is a fix 17ba9cde11c2bfebbd70867b0a2ac4a22e573379 introduced in v6.8 to fix the problem introduced by the original fix 66951d98d9bf45ba25acf37fe0747253fafdf298, and they together fix the CVE-2024-26661. Since this is the first time I submit the changes on vulns project, not sure if the changes in my patch are exact, @Greg, please point out the problems if there are and I will fix them. Thanks! Qingfeng Hao (1): CVE-2024-26661: change the sha1 of the cve id cve/published/2024/CVE-2024-26661.dyad | 6 ++-- cve/published/2024/CVE-2024-26661.json | 46 ++------------------------ cve/published/2024/CVE-2024-26661.sha1 | 2 +- 3 files changed, 5 insertions(+), 49 deletions(-) -- 2.34.1

2 weeks, 3 days

4
6
0 0

[PATCH] clk: qcom: tcsrcc-x1e80100: Set the bi_tcxo as parent to eDP refclk

by Abel Vesa

All the other ref clocks provided by this driver have the bi_tcxo as parent. The eDP refclk is the only one without a parent, leading to reporting its rate as 0. So set its parent to bi_tcxo, just like the rest of the refclks. Cc: stable(a)vger.kernel.org # v6.9 Fixes: 06aff116199c ("clk: qcom: Add TCSR clock driver for x1e80100") Signed-off-by: Abel Vesa <abel.vesa(a)linaro.org> --- drivers/clk/qcom/tcsrcc-x1e80100.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/clk/qcom/tcsrcc-x1e80100.c b/drivers/clk/qcom/tcsrcc-x1e80100.c index ff61769a08077e916157a03c789ab3d5b0c090f6..a367e1f55622d990929984facb62185b551d6c50 100644 --- a/drivers/clk/qcom/tcsrcc-x1e80100.c +++ b/drivers/clk/qcom/tcsrcc-x1e80100.c @@ -29,6 +29,10 @@ static struct clk_branch tcsr_edp_clkref_en = { .enable_mask = BIT(0), .hw.init = &(const struct clk_init_data) { .name = "tcsr_edp_clkref_en", + .parent_data = &(const struct clk_parent_data){ + .index = DT_BI_TCXO_PAD, + }, + .num_parents = 1, .ops = &clk_branch2_ops, }, }, --- base-commit: 79fb37f39b77bbf9a56304e9af843cd93a7a1916 change-id: 20250730-clk-qcom-tcsrcc-x1e80100-parent-edp-refclk-8b17a56f050a Best regards, -- Abel Vesa <abel.vesa(a)linaro.org>

2 weeks, 3 days

3
2
0 0

[PATCH] mm: Fix possible deadlock in console_trylock_spinning

by Gu Bowen

kmemleak_scan_thread() invokes scan_block() which may invoke a nomal printk() to print warning message. This can cause a deadlock in the scenario reported below: CPU0 CPU1 ---- ---- lock(kmemleak_lock); lock(&port->lock); lock(kmemleak_lock); lock(console_owner); To solve this problem, switch to printk_safe mode before printing warning message, this will redirect all printk()-s to a special per-CPU buffer, which will be flushed later from a safe context (irq work), and this deadlock problem can be avoided. Our syztester report the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.10.0-22221-gca646a51dd00 #16 Not tainted ------------------------------------------------------ kmemleak/182 is trying to acquire lock: ffffffffaf9e9020 (console_owner){-...}-{0:0}, at: console_trylock_spinning+0xda/0x1d0 kernel/printk/printk.c:1900 but task is already holding lock: ffffffffb007cf58 (kmemleak_lock){-.-.}-{2:2}, at: scan_block+0x3d/0x220 mm/kmemleak.c:1310 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kmemleak_lock){-.-.}-{2:2}: validate_chain+0x5df/0xac0 kernel/locking/lockdep.c:3729 __lock_acquire+0x514/0x940 kernel/locking/lockdep.c:4958 lock_acquire+0x15a/0x3a0 kernel/locking/lockdep.c:5569 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x3b/0x60 kernel/locking/spinlock.c:164 create_object.isra.0+0x36/0x80 mm/kmemleak.c:691 kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] slab_post_alloc_hook mm/slab.h:518 [inline] slab_alloc_node mm/slub.c:2987 [inline] slab_alloc mm/slub.c:2995 [inline] __kmalloc+0x637/0xb60 mm/slub.c:4100 kmalloc include/linux/slab.h:620 [inline] tty_buffer_alloc+0x127/0x140 drivers/tty/tty_buffer.c:176 __tty_buffer_request_room+0x9b/0x110 drivers/tty/tty_buffer.c:276 tty_insert_flip_string_fixed_flag+0x60/0x130 drivers/tty/tty_buffer.c:321 tty_insert_flip_string include/linux/tty_flip.h:36 [inline] tty_insert_flip_string_and_push_buffer+0x3a/0xb0 drivers/tty/tty_buffer.c:578 process_output_block+0xc2/0x2e0 drivers/tty/n_tty.c:592 n_tty_write+0x298/0x540 drivers/tty/n_tty.c:2433 do_tty_write drivers/tty/tty_io.c:1041 [inline] file_tty_write.constprop.0+0x29b/0x4b0 drivers/tty/tty_io.c:1147 redirected_tty_write+0x51/0x90 drivers/tty/tty_io.c:1176 call_write_iter include/linux/fs.h:2117 [inline] do_iter_readv_writev+0x274/0x350 fs/read_write.c:741 do_iter_write+0xbb/0x1f0 fs/read_write.c:867 vfs_writev+0xfa/0x380 fs/read_write.c:940 do_writev+0xd6/0x1d0 fs/read_write.c:983 do_syscall_64+0x2b/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x6c/0xd6 -> #2 (&port->lock){-.-.}-{2:2}: validate_chain+0x5df/0xac0 kernel/locking/lockdep.c:3729 __lock_acquire+0x514/0x940 kernel/locking/lockdep.c:4958 lock_acquire+0x15a/0x3a0 kernel/locking/lockdep.c:5569 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x3b/0x60 kernel/locking/spinlock.c:164 tty_port_tty_get+0x1f/0xa0 drivers/tty/tty_port.c:289 tty_port_default_wakeup+0xb/0x30 drivers/tty/tty_port.c:48 serial8250_tx_chars+0x259/0x430 drivers/tty/serial/8250/8250_port.c:1906 __start_tx drivers/tty/serial/8250/8250_port.c:1598 [inline] serial8250_start_tx+0x304/0x320 drivers/tty/serial/8250/8250_port.c:1720 uart_write+0x1a1/0x2e0 drivers/tty/serial/serial_core.c:635 do_output_char+0x2c0/0x370 drivers/tty/n_tty.c:444 process_output drivers/tty/n_tty.c:511 [inline] n_tty_write+0x269/0x540 drivers/tty/n_tty.c:2445 do_tty_write drivers/tty/tty_io.c:1041 [inline] file_tty_write.constprop.0+0x29b/0x4b0 drivers/tty/tty_io.c:1147 call_write_iter include/linux/fs.h:2117 [inline] do_iter_readv_writev+0x274/0x350 fs/read_write.c:741 do_iter_write+0xbb/0x1f0 fs/read_write.c:867 vfs_writev+0xfa/0x380 fs/read_write.c:940 do_writev+0xd6/0x1d0 fs/read_write.c:983 do_syscall_64+0x2b/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x6c/0xd6 -> #1 (&port_lock_key){-.-.}-{2:2}: validate_chain+0x5df/0xac0 kernel/locking/lockdep.c:3729 __lock_acquire+0x514/0x940 kernel/locking/lockdep.c:4958 lock_acquire+0x15a/0x3a0 kernel/locking/lockdep.c:5569 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x3b/0x60 kernel/locking/spinlock.c:164 serial8250_console_write+0x292/0x320 drivers/tty/serial/8250/8250_port.c:3458 call_console_drivers.constprop.0+0x185/0x240 kernel/printk/printk.c:1988 console_unlock+0x2b4/0x640 kernel/printk/printk.c:2648 register_console.part.0+0x2a1/0x390 kernel/printk/printk.c:3024 univ8250_console_init+0x24/0x2b drivers/tty/serial/8250/8250_core.c:724 console_init+0x188/0x24b kernel/printk/printk.c:3134 start_kernel+0x2b0/0x41e init/main.c:1072 secondary_startup_64_no_verify+0xc3/0xcb -> #0 (console_owner){-...}-{0:0}: check_prev_add+0xfa/0x1380 kernel/locking/lockdep.c:2988 check_prevs_add+0x1d8/0x3c0 kernel/locking/lockdep.c:3113 validate_chain+0x5df/0xac0 kernel/locking/lockdep.c:3729 __lock_acquire+0x514/0x940 kernel/locking/lockdep.c:4958 lock_acquire+0x15a/0x3a0 kernel/locking/lockdep.c:5569 console_trylock_spinning+0x10d/0x1d0 kernel/printk/printk.c:1921 vprintk_emit+0x1a5/0x270 kernel/printk/printk.c:2134 printk+0xb2/0xe7 kernel/printk/printk.c:2183 lookup_object.cold+0xf/0x24 mm/kmemleak.c:405 scan_block+0x1fa/0x220 mm/kmemleak.c:1357 scan_object+0xdd/0x140 mm/kmemleak.c:1415 scan_gray_list+0x8f/0x1c0 mm/kmemleak.c:1453 kmemleak_scan+0x649/0xf30 mm/kmemleak.c:1608 kmemleak_scan_thread+0x94/0xb6 mm/kmemleak.c:1721 kthread+0x1c4/0x210 kernel/kthread.c:328 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:299 other info that might help us debug this: Chain exists of: console_owner --> &port->lock --> kmemleak_lock Cc: stable(a)vger.kernel.org # 5.10 Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- mm/kmemleak.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/kmemleak.c b/mm/kmemleak.c index 4801751cb6b6..d322897a1de1 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -390,9 +390,11 @@ static struct kmemleak_object *lookup_object(unsigned long ptr, int alias) else if (object->pointer == ptr || alias) return object; else { + __printk_safe_enter(); kmemleak_warn("Found object by alias at 0x%08lx\n", ptr); dump_object_info(object); + __printk_safe_exit(); break; } } -- 2.25.1

2 weeks, 3 days

7
11
0 0

Re: Patch "ARM: s3c/gpio: complete the conversion to new GPIO value setters" has been added to the 6.16-stable tree

by Bartosz Golaszewski

On Mon, 11 Aug 2025 at 16:18, Sasha Levin <sashal(a)kernel.org> wrote: > > This is a note to let you know that I've just added the patch titled > > ARM: s3c/gpio: complete the conversion to new GPIO value setters > > to the 6.16-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > arm-s3c-gpio-complete-the-conversion-to-new-gpio-val.patch > and it can be found in the queue-6.16 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > This is not something we should backport. This is a refactoring targeting v6.17. Bartosz > > > commit c09ce1148e4748b856b6d13a8b9fa568a1e687a2 > Author: Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> > Date: Wed Jul 30 09:14:43 2025 +0200 > > ARM: s3c/gpio: complete the conversion to new GPIO value setters > > [ Upstream commit 3dca3d51b933beb3f35a60472ed2110d1bd7046a ] > > Commit fb52f3226cab ("ARM: s3c/gpio: use new line value setter > callbacks") correctly changed the assignment of the callback but missed > the check one liner higher. Change it now too to using the recommended > callback as the legacy one is going away soon. > > Fixes: fb52f3226cab ("ARM: s3c/gpio: use new line value setter callbacks") > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> > Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/arch/arm/mach-s3c/gpio-samsung.c b/arch/arm/mach-s3c/gpio-samsung.c > index 206a492fbaf5..3ee4ad969cc2 100644 > --- a/arch/arm/mach-s3c/gpio-samsung.c > +++ b/arch/arm/mach-s3c/gpio-samsung.c > @@ -516,7 +516,7 @@ static void __init samsung_gpiolib_add(struct samsung_gpio_chip *chip) > gc->direction_input = samsung_gpiolib_2bit_input; > if (!gc->direction_output) > gc->direction_output = samsung_gpiolib_2bit_output; > - if (!gc->set) > + if (!gc->set_rv) > gc->set_rv = samsung_gpiolib_set; > if (!gc->get) > gc->get = samsung_gpiolib_get;

2 weeks, 3 days

1
0
0 0

[PATCH 0/2] mfd: vexpress: convert the driver to using the new generic GPIO chip API

by Bartosz Golaszewski

This converts the vexpress-sysreg MFD driver to using the new generic GPIO interface but first fixes an issue with an unchecked return value of devm_gpiochio_add_data(). Lee: Please, create an immutable branch containing these commits after you pick them up, as I'd like to merge it into the GPIO tree and remove the legacy interface in this cycle. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> --- Bartosz Golaszewski (2): mfd: vexpress-sysreg: check the return value of devm_gpiochip_add_data() mfd: vexpress-sysreg: use new generic GPIO chip API drivers/mfd/vexpress-sysreg.c | 25 ++++++++++++++++++++----- 1 file changed, 20 insertions(+), 5 deletions(-) --- base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585 change-id: 20250728-gpio-mmio-mfd-conv-d27c2cfbccfe Best regards, -- Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org>

2 weeks, 3 days

1
1
0 0

[PATCH v3] arm64: dts: st: Add memory-region-names property for stm32mp257f-ev1

by Patrice Chotard

In order to set the AMCR register, which configures the memory-region split between ospi1 and ospi2, we need to identify the ospi instance. By using memory-region-names, it allows to identify the ospi instance this memory-region belongs to. Fixes: cad2492de91c ("arm64: dts: st: Add SPI NOR flash support on stm32mp257f-ev1 board") Cc: stable(a)vger.kernel.org Signed-off-by: Patrice Chotard <patrice.chotard(a)foss.st.com> --- Changes in v3: - Set again "Cc: <stable(a)vger.kernel.org>" - Link to v2: https://lore.kernel.org/r/20250811-upstream_fix_dts_omm-v2-1-00ff55076bd5@f… Changes in v2: - Update commit message. - Use correct memory-region-names value. - Remove "Cc: <stable(a)vger.kernel.org>" tag as the fixed patch is not part of a LTS. - Link to v1: https://lore.kernel.org/r/20250806-upstream_fix_dts_omm-v1-1-e68c15ed422d@f… --- arch/arm64/boot/dts/st/stm32mp257f-ev1.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts index 2f561ad4066544445e93db78557bc4be1c27095a..7bd8433c1b4344bb5d58193a5e6314f9ae89e0a4 100644 --- a/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts +++ b/arch/arm64/boot/dts/st/stm32mp257f-ev1.dts @@ -197,6 +197,7 @@ &i2c8 { &ommanager { memory-region = <&mm_ospi1>; + memory-region-names = "ospi1"; pinctrl-0 = <&ospi_port1_clk_pins_a &ospi_port1_io03_pins_a &ospi_port1_cs0_pins_a>; --- base-commit: 038d61fd642278bab63ee8ef722c50d10ab01e8f change-id: 20250806-upstream_fix_dts_omm-c006b69042f1 Best regards, -- Patrice Chotard <patrice.chotard(a)foss.st.com>

2 weeks, 3 days

1
0
0 0

[PATCH V4 mm-hotfixes 1/3] mm: move page table sync declarations to linux/pgtable.h

by Harry Yoo

Move ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to linux/pgtable.h so that they can be used outside of vmalloc and ioremap. Cc: <stable(a)vger.kernel.org> Fixes: 8d400913c231 ("x86/vmemmap: handle unpopulated sub-pmd ranges") Signed-off-by: Harry Yoo <harry.yoo(a)oracle.com> --- include/linux/pgtable.h | 16 ++++++++++++++++ include/linux/vmalloc.h | 16 ---------------- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h index 4c035637eeb7..ba699df6ef69 100644 --- a/include/linux/pgtable.h +++ b/include/linux/pgtable.h @@ -1467,6 +1467,22 @@ static inline void modify_prot_commit_ptes(struct vm_area_struct *vma, unsigned } #endif +/* + * Architectures can set this mask to a combination of PGTBL_P?D_MODIFIED values + * and let generic vmalloc and ioremap code know when arch_sync_kernel_mappings() + * needs to be called. + */ +#ifndef ARCH_PAGE_TABLE_SYNC_MASK +#define ARCH_PAGE_TABLE_SYNC_MASK 0 +#endif + +/* + * There is no default implementation for arch_sync_kernel_mappings(). It is + * relied upon the compiler to optimize calls out if ARCH_PAGE_TABLE_SYNC_MASK + * is 0. + */ +void arch_sync_kernel_mappings(unsigned long start, unsigned long end); + #endif /* CONFIG_MMU */ /* diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h index fdc9aeb74a44..2759dac6be44 100644 --- a/include/linux/vmalloc.h +++ b/include/linux/vmalloc.h @@ -219,22 +219,6 @@ extern int remap_vmalloc_range(struct vm_area_struct *vma, void *addr, int vmap_pages_range(unsigned long addr, unsigned long end, pgprot_t prot, struct page **pages, unsigned int page_shift); -/* - * Architectures can set this mask to a combination of PGTBL_P?D_MODIFIED values - * and let generic vmalloc and ioremap code know when arch_sync_kernel_mappings() - * needs to be called. - */ -#ifndef ARCH_PAGE_TABLE_SYNC_MASK -#define ARCH_PAGE_TABLE_SYNC_MASK 0 -#endif - -/* - * There is no default implementation for arch_sync_kernel_mappings(). It is - * relied upon the compiler to optimize calls out if ARCH_PAGE_TABLE_SYNC_MASK - * is 0. - */ -void arch_sync_kernel_mappings(unsigned long start, unsigned long end); - /* * Lowlevel-APIs (not for driver use!) */ -- 2.43.0

2 weeks, 3 days

4
5
0 0

[PATCH] PCI: rcar-gen4: Fix PHY initialization

by Marek Vasut

R-Car V4H Reference Manual R19UH0186EJ0130 Rev.1.30 Apr. 21, 2025 page 4581 Figure 104.3b Initial Setting of PCIEC(example) middle of the figure indicates that fourth write into register 0x148 [2:0] is 0x3 or GENMASK(1, 0). The current code writes GENMASK(11, 0) which is a typo. Fix the typo. Fixes: faf5a975ee3b ("PCI: rcar-gen4: Add support for R-Car V4H") Cc: <stable(a)vger.kernel.org> Signed-off-by: Marek Vasut <marek.vasut+renesas(a)mailbox.org> --- Cc: "Krzysztof Wilczyński" <kwilczynski(a)kernel.org> Cc: Bjorn Helgaas <bhelgaas(a)google.com> Cc: Geert Uytterhoeven <geert+renesas(a)glider.be> Cc: Lorenzo Pieralisi <lpieralisi(a)kernel.org> Cc: Magnus Damm <magnus.damm(a)gmail.com> Cc: Manivannan Sadhasivam <mani(a)kernel.org> Cc: Rob Herring <robh(a)kernel.org> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> Cc: linux-pci(a)vger.kernel.org Cc: linux-renesas-soc(a)vger.kernel.org --- drivers/pci/controller/dwc/pcie-rcar-gen4.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c index f256ba12b84f..0ef95005b0f5 100644 --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c @@ -703,7 +703,7 @@ static int rcar_gen4_pcie_ltssm_control(struct rcar_gen4_pcie *rcar, bool enable rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x148, GENMASK(23, 22), BIT(22)); rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x148, GENMASK(18, 16), GENMASK(17, 16)); rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x148, GENMASK(7, 6), BIT(6)); - rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x148, GENMASK(2, 0), GENMASK(11, 0)); + rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x148, GENMASK(2, 0), GENMASK(1, 0)); rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x1d4, GENMASK(16, 15), GENMASK(16, 15)); rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x514, BIT(26), BIT(26)); rcar_gen4_pcie_phy_reg_update_bits(rcar, 0x0f8, BIT(16), 0); -- 2.47.2

2 weeks, 3 days

2
1
0 0

[PATCH 4/4] smb: client: fix potential UAF in cifs_stats_proc_write()

by Chanho Min

From: Paulo Alcantara <pc(a)manguebit.com> commit d3da25c5ac84430f89875ca7485a3828150a7e0a upstream. Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF. Cc: stable(a)vger.kernel.org # 5.4 Signed-off-by: Paulo Alcantara (Red Hat) <pc(a)manguebit.com> Signed-off-by: Steve French <stfrench(a)microsoft.com> [ chanho: Backported to v5.4.y, cifs_debug.c was moved from fs/cifs to fs/smb/client ] Signed-off-by: Chanho Min <chanho.min(a)lge.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/cifs/cifs_debug.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/cifs/cifs_debug.c b/fs/cifs/cifs_debug.c index df3dfa611c352..47190e676aa25 100644 --- a/fs/cifs/cifs_debug.c +++ b/fs/cifs/cifs_debug.c @@ -470,6 +470,8 @@ static ssize_t cifs_stats_proc_write(struct file *file, } #endif /* CONFIG_CIFS_STATS2 */ list_for_each(tmp2, &server->smb_ses_list) { + if (cifs_ses_exiting(ses)) + continue; ses = list_entry(tmp2, struct cifs_ses, smb_ses_list); list_for_each(tmp3, &ses->tcon_list) {

2 weeks, 3 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror