August 2025 - Linux-stable-mirror

+ mm-fix-accounting-of-memmap-pages-for-early-sections.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: fix accounting of memmap pages for early sections has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-fix-accounting-of-memmap-pages-for-early-sections.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: Sumanth Korikkar <sumanthk(a)linux.ibm.com> Subject: mm: fix accounting of memmap pages for early sections Date: Mon, 4 Aug 2025 10:40:15 +0200 memmap pages can be allocated either from the memblock (boot) allocator during early boot or from the buddy allocator. When these memmap pages are removed via arch_remove_memory(), the deallocation path depends on their source: * For pages from the buddy allocator, depopulate_section_memmap() is called, which also decrements the count of nr_memmap_pages. * For pages from the boot allocator, free_map_bootmem() is called. But it currently does not adjust the nr_memmap_boot_pages. To fix this inconsistency, update free_map_bootmem() to also decrement the nr_memmap_boot_pages count by invoking memmap_boot_pages_add(), mirroring how free_vmemmap_page() handles this for boot-allocated pages. This ensures correct tracking of memmap pages regardless of allocation source. Link: https://lkml.kernel.org/r/20250804084015.270570-1-sumanthk@linux.ibm.com Fixes: 15995a352474 ("mm: report per-page metadata information") Signed-off-by: Sumanth Korikkar <sumanthk(a)linux.ibm.com> Cc: Alexander Gordeev <agordeev(a)linux.ibm.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Gerald Schaefer <gerald.schaefer(a)linux.ibm.com> Cc: Heiko Carstens <hca(a)linux.ibm.com> Cc: Vasily Gorbik <gor(a)linux.ibm.com> Cc: David Rientjes <rientjes(a)google.com> Cc: Pasha Tatashin <pasha.tatashin(a)soleen.com> Cc: Sourav Panda <souravpanda(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/sparse.c | 1 + 1 file changed, 1 insertion(+) --- a/mm/sparse.c~mm-fix-accounting-of-memmap-pages-for-early-sections +++ a/mm/sparse.c @@ -688,6 +688,7 @@ static void free_map_bootmem(struct page unsigned long start = (unsigned long)memmap; unsigned long end = (unsigned long)(memmap + PAGES_PER_SECTION); + memmap_boot_pages_add(-1L * (DIV_ROUND_UP(end - start, PAGE_SIZE))); vmemmap_free(start, end, NULL); } _ Patches currently in -mm which might be from sumanthk(a)linux.ibm.com are mm-fix-accounting-of-memmap-pages-for-early-sections.patch

4 days, 13 hours

1
0
0 0

[PATCH v5] x86/cpu/intel: Fix the constant_tsc model check for Pentium 4

by Suchit Karunakaran

Pentium 4's which are INTEL_P4_PRESCOTT (model 0x03) and later have a constant TSC. This was correctly captured until commit fadb6f569b10 ("x86/cpu/intel: Limit the non-architectural constant_tsc model checks"). In that commit, an error was introduced while selecting the last P4 model (0x06) as the upper bound. Model 0x06 was transposed to INTEL_P4_WILLAMETTE, which is just plain wrong. That was presumably a simple typo, probably just copying and pasting the wrong P4 model. Fix the constant TSC logic to cover all later P4 models. End at INTEL_P4_CEDARMILL which accurately corresponds to the last P4 model. Fixes: fadb6f569b10 ("x86/cpu/intel: Limit the non-architectural constant_tsc model checks") Cc: <stable(a)vger.kernel.org> # v6.15 Signed-off-by: Suchit Karunakaran <suchitkarunakaran(a)gmail.com> --- Changes since v4: - Updated the patch based on review suggestions Changes since v3: - Refined changelog Changes since v2: - Improved commit message Changes since v1: - Fixed incorrect logic arch/x86/kernel/cpu/intel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index 076eaa41b8c8..98ae4c37c93e 100644 --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -262,7 +262,7 @@ static void early_init_intel(struct cpuinfo_x86 *c) if (c->x86_power & (1 << 8)) { set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC); set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC); - } else if ((c->x86_vfm >= INTEL_P4_PRESCOTT && c->x86_vfm <= INTEL_P4_WILLAMETTE) || + } else if ((c->x86_vfm >= INTEL_P4_PRESCOTT && c->x86_vfm <= INTEL_P4_CEDARMILL) || (c->x86_vfm >= INTEL_CORE_YONAH && c->x86_vfm <= INTEL_IVYBRIDGE)) { set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC); } -- 2.50.1

4 days, 14 hours

2
2
0 0

[PATCH 5.15.y] KVM: arm64: sys_regs: disable -Wuninitialized-const-pointer warning

by Justin Stitt

A new warning in Clang 22 [1] complains that @clidr passed to get_clidr_el1() is an uninitialized const pointer. get_clidr_el1() doesn't really care since it casts away the const-ness anyways -- it is a false positive. | ../arch/arm64/kvm/sys_regs.c:2838:23: warning: variable 'clidr' is uninitialized when passed as a const pointer argument here [-Wuninitialized-const-pointer] | 2838 | get_clidr_el1(NULL, &clidr); /* Ugly... */ | | ^~~~~ Disable this warning for sys_regs.o with an iron fist as it doesn't make sense to waste maintainer's time or potentially break builds by backporting large changelists from 6.2+. This patch isn't needed for anything past 6.1 as this code section was reworked in Commit 7af0c2534f4c ("KVM: arm64: Normalize cache configuration"). Cc: stable(a)vger.kernel.org Fixes: 7c8c5e6a9101e ("arm64: KVM: system register handling") Link: https://github.com/llvm/llvm-project/commit/00dacf8c22f065cb52efb14cd091d44… [1] Signed-off-by: Justin Stitt <justinstitt(a)google.com> --- I'm sending a similar patch for 6.1. --- arch/arm64/kvm/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile index 989bb5dad2c8..109cca425d3e 100644 --- a/arch/arm64/kvm/Makefile +++ b/arch/arm64/kvm/Makefile @@ -25,3 +25,6 @@ kvm-y := $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o \ vgic/vgic-its.o vgic/vgic-debug.o kvm-$(CONFIG_HW_PERF_EVENTS) += pmu-emul.o + +# Work around a false positive Clang 22 -Wuninitialized-const-pointer warning +CFLAGS_sys_regs.o := $(call cc-disable-warning, uninitialized-const-pointer) --- base-commit: 8bb7eca972ad531c9b149c0a51ab43a417385813 change-id: 20250728-b4-stable-disable-uninit-ptr-warn-5-15-c0c9db3df206 Best regards, -- Justin Stitt <justinstitt(a)google.com>

4 days, 15 hours

3
2
0 0

[PATCH 6.1.y] KVM: arm64: sys_regs: disable -Wuninitialized-const-pointer warning

by Justin Stitt

A new warning in Clang 22 [1] complains that @clidr passed to get_clidr_el1() is an uninitialized const pointer. get_clidr_el1() doesn't really care since it casts away the const-ness anyways -- it is a false positive. | ../arch/arm64/kvm/sys_regs.c:2978:23: warning: variable 'clidr' is uninitialized when passed as a const pointer argument here [-Wuninitialized-const-pointer] | 2978 | get_clidr_el1(NULL, &clidr); /* Ugly... */ | | ^~~~~ Disable this warning for sys_regs.o with an iron fist as it doesn't make sense to waste maintainer's time or potentially break builds by backporting large changelists from 6.2+. This patch isn't needed for anything past 6.1 as this code section was reworked in Commit 7af0c2534f4c ("KVM: arm64: Normalize cache configuration"). Cc: stable(a)vger.kernel.org Fixes: 7c8c5e6a9101e ("arm64: KVM: system register handling") Link: https://github.com/llvm/llvm-project/commit/00dacf8c22f065cb52efb14cd091d44… [1] Signed-off-by: Justin Stitt <justinstitt(a)google.com> --- I've sent a similar patch for 5.15. --- arch/arm64/kvm/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile index 5e33c2d4645a..5fdb5331bfad 100644 --- a/arch/arm64/kvm/Makefile +++ b/arch/arm64/kvm/Makefile @@ -24,6 +24,9 @@ kvm-y += arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \ kvm-$(CONFIG_HW_PERF_EVENTS) += pmu-emul.o pmu.o +# Work around a false positive Clang 22 -Wuninitialized-const-pointer warning +CFLAGS_sys_regs.o := $(call cc-disable-warning, uninitialized-const-pointer) + always-y := hyp_constants.h hyp-constants.s define rule_gen_hyp_constants --- base-commit: 830b3c68c1fb1e9176028d02ef86f3cf76aa2476 change-id: 20250728-stable-disable-unit-ptr-warn-281fee82539c Best regards, -- Justin Stitt <justinstitt(a)google.com>

4 days, 15 hours

3
2
0 0

+ userfaultfd-fix-a-crash-in-uffdio_move-when-pmd-is-a-migration-entry.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: userfaultfd: fix a crash in UFFDIO_MOVE when PMD is a migration entry has been added to the -mm mm-hotfixes-unstable branch. Its filename is userfaultfd-fix-a-crash-in-uffdio_move-when-pmd-is-a-migration-entry.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: 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. Link: https://lkml.kernel.org/r/20250806220022.926763-1-surenb@google.com Fixes: adef440691ba ("userfaultfd: UFFDIO_MOVE uABI") Reported-by: syzbot+b446dbe27035ef6bd6c2(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68794b5c.a70a0220.693ce.0050.GAE@google.com/ Signed-off-by: Suren Baghdasaryan <surenb(a)google.com> Reviewed-by: Peter Xu <peterx(a)redhat.com> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: David Hildenbrand <david(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 (!folio || (!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 userfaultfd-fix-a-crash-in-uffdio_move-when-pmd-is-a-migration-entry.patch mm-limit-the-scope-of-vma_start_read.patch mm-change-vma_start_read-to-drop-rcu-lock-on-failure.patch

4 days, 15 hours

1
0
0 0

[PATCH v3 1/1] userfaultfd: fix a crash in UFFDIO_MOVE with some non-present PMDs

by Suren Baghdasaryan

When UFFDIO_MOVE is used with UFFDIO_MOVE_MODE_ALLOW_SRC_HOLES and it encounters a non-present PMD (migration entry), it proceeds with folio access even though the folio is not present. Add the missing check and let split_huge_pmd() handle migration entries. Fixes: adef440691ba ("userfaultfd: UFFDIO_MOVE uABI") Reported-by: syzbot+b446dbe27035ef6bd6c2(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/68794b5c.a70a0220.693ce.0050.GAE@google.com/ Signed-off-by: Suren Baghdasaryan <surenb(a)google.com> Cc: stable(a)vger.kernel.org --- Changes since v2 [1] - Updated the title and changelog, per David Hildenbrand - Removed extra checks for non-present not-migration PMD entries, per Peter Xu [1] https://lore.kernel.org/all/20250731154442.319568-1-surenb@google.com/ mm/userfaultfd.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c index 5431c9dd7fd7..116481606be8 100644 --- a/mm/userfaultfd.c +++ b/mm/userfaultfd.c @@ -1826,13 +1826,16 @@ ssize_t move_pages(struct userfaultfd_ctx *ctx, unsigned long dst_start, /* 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); - - if (!folio || (!is_huge_zero_folio(folio) && - !PageAnonExclusive(&folio->page))) { - spin_unlock(ptl); - err = -EBUSY; - break; + /* 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; + } } spin_unlock(ptl); base-commit: 8e7e0c6d09502e44aa7a8fce0821e042a6ec03d1 -- 2.50.1.565.gc32cd1483b-goog

4 days, 15 hours

2
5
0 0

[PATCH 6.6 v2 0/7] x86: fix user address masking non-canonical

by Jimmy Tran

Hi everyone, This is v2 of my series to backport the critical security fix, identified as CVE-2020-12965 ("Transient Execution of Non-Canonical Accesses"), to the 6.6.y stable kernel tree. Linus Torvalds's second proposed solution offers a more targeted and smaller backport for CVE-2020-12965 compared to backporting the entire patch series. This alternative would focus solely on the user address masking logic that addresses the AMD speculation issue with non-canonical addresses. Instead of introducing the extensive "runtime-constant" infrastructure seen in the larger patch series, this solution would: - Introduce a single new variable for the USER_PTR_MAX value. - Use an actual memory load to access this USER_PTR_MAX value, rather than leveraging the runtime_const mechanism. While this approach would result in a noticeably smaller and more localized patch, it would differ from what's currently in the mainline kernel. This divergence would necessitate significant additional testing to ensure its stability. I am ready to implement the second proposed solution if the maintainers wish to move forward in that direction, understanding the testing implications. Please let me know your preference. Changes in v2: ============== - Incorporated the commit 91309a708: x86: use cmov for user address as suggested by David Laight. This commit is now included as the first patch in the series. This series addresses the CVE-2020-12965 vulnerability by introducing the necessary x86 infrastructure and the specific fix for user address masking non-canonical speculation issues. v1: ============== This patch series backports a critical security fix, identified as CVE-2020-12965 ("Transient Execution of Non-Canonical Accesses"), to the 6.6.y stable kernel tree. David Laight (1): x86: fix off-by-one in access_ok() Linus Torvalds (6): vfs: dcache: move hashlen_hash() from callers into d_hash() runtime constants: add default dummy infrastructure runtime constants: add x86 architecture support arm64: add 'runtime constant' support x86: fix user address masking non-canonical speculation issue x86: use cmov for user address masking arch/arm64/include/asm/runtime-const.h | 92 ++++++++++++++++++++++++++ arch/arm64/kernel/vmlinux.lds.S | 3 + arch/x86/include/asm/runtime-const.h | 61 +++++++++++++++++ arch/x86/include/asm/uaccess_64.h | 44 +++++++----- arch/x86/kernel/cpu/common.c | 10 +++ arch/x86/kernel/vmlinux.lds.S | 4 ++ arch/x86/lib/getuser.S | 10 ++- fs/dcache.c | 17 +++-- include/asm-generic/Kbuild | 1 + include/asm-generic/runtime-const.h | 15 +++++ include/asm-generic/vmlinux.lds.h | 8 +++ 11 files changed, 242 insertions(+), 23 deletions(-) create mode 100644 arch/arm64/include/asm/runtime-const.h create mode 100644 arch/x86/include/asm/runtime-const.h create mode 100644 include/asm-generic/runtime-const.h -- 2.50.1.470.g6ba607880d-goog

4 days, 16 hours

3
9
0 0

[PATCH net v3] net: usbnet: Fix the wrong netif_carrier_on() call

by Ammar Faizi

The commit referenced in the Fixes tag causes usbnet to malfunction (identified via git bisect). Post-commit, my external RJ45 LAN cable fails to connect. Linus also reported the same issue after pulling that commit. The code has a logic error: netif_carrier_on() is only called when the link is already on. Fix this by moving the netif_carrier_on() call outside the if-statement entirely. This ensures it is always called when EVENT_LINK_CARRIER_ON is set and properly clears it regardless of the link state. Cc: stable(a)vger.kernel.org Cc: Armando Budianto <sprite(a)gnuweeb.org> Reviewed-by: Simon Horman <horms(a)kernel.org> Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org> Link: https://lore.kernel.org/all/CAHk-=wjqL4uF0MG_c8+xHX1Vv8==sPYQrtzbdA3kzi9628… Closes: https://lore.kernel.org/netdev/CAHk-=wjKh8X4PT_mU1kD4GQrbjivMfPn-_hXa6han_B… Closes: https://lore.kernel.org/netdev/0752dee6-43d6-4e1f-81d2-4248142cccd2@gnuweeb… Fixes: 0d9cfc9b8cb1 ("net: usbnet: Avoid potential RCU stall on LINK_CHANGE event") Signed-off-by: Ammar Faizi <ammarfaizi2(a)gnuweeb.org> --- v3: - Move the netif_carrier_on() call outside of the if-statement entirely (Linus). v2: - Rebase on top of the latest netdev/net tree. The previous patch was based on 0d9cfc9b8cb1. Line numbers have changed since then. Link: https://lore.gnuweeb.org/gwml/20250801190310.58443-1-ammarfaizi2@gnuweeb.org drivers/net/usb/usbnet.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c index a38ffbf4b3f0..511c4154cf74 100644 --- a/drivers/net/usb/usbnet.c +++ b/drivers/net/usb/usbnet.c @@ -1113,32 +1113,32 @@ static const struct ethtool_ops usbnet_ethtool_ops = { .set_link_ksettings = usbnet_set_link_ksettings_mii, }; /*-------------------------------------------------------------------------*/ static void __handle_link_change(struct usbnet *dev) { if (!test_bit(EVENT_DEV_OPEN, &dev->flags)) return; + if (test_and_clear_bit(EVENT_LINK_CARRIER_ON, &dev->flags)) + netif_carrier_on(dev->net); + if (!netif_carrier_ok(dev->net)) { /* kill URBs for reading packets to save bus bandwidth */ unlink_urbs(dev, &dev->rxq); /* * tx_timeout will unlink URBs for sending packets and * tx queue is stopped by netcore after link becomes off */ } else { - if (test_and_clear_bit(EVENT_LINK_CARRIER_ON, &dev->flags)) - netif_carrier_on(dev->net); - /* submitting URBs for reading packets */ queue_work(system_bh_wq, &dev->bh_work); } /* hard_mtu or rx_urb_size may change during link change */ usbnet_update_max_qlen(dev); clear_bit(EVENT_LINK_CHANGE, &dev->flags); } -- Ammar Faizi

4 days, 18 hours

2
1
0 0

[PATCH] 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 Signed-off-by: Fabio Porcedda <fabio.porcedda(a)gmail.com> --- 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

4 days, 19 hours

2
1
0 0

[PATCH 5.10.y 0/4] Backport series: "permit write-sealed memfd read-only shared mappings"

by Isaac J. Manjarres

Hello, Until kernel version 6.7, a write-sealed memfd could not be mapped as shared and read-only. This was clearly a bug, and was not inline with the description of F_SEAL_WRITE in the man page for fcntl()[1]. Lorenzo's series [2] fixed that issue and was merged in kernel version 6.7, but was not backported to older kernels. So, this issue is still present on kernels 5.4, 5.10, 5.15, 6.1, and 6.6. This series consists of backports of two of Lorenzo's series [2] and [3]. Note: for [2], I dropped the last patch in that series, since it wouldn't make sense to apply it due to [4] being part of this tree. In lieu of that, I backported [3] to ultimately allow write-sealed memfds to be mapped as read-only. [1] https://man7.org/linux/man-pages/man2/fcntl.2.html [2] https://lore.kernel.org/all/913628168ce6cce77df7d13a63970bae06a526e0.169711… [3] https://lkml.kernel.org/r/99fc35d2c62bd2e05571cf60d9f8b843c56069e0.17328047… [4] https://lore.kernel.org/all/6e0becb36d2f5472053ac5d544c0edfe9b899e25.173022… Lorenzo Stoakes (4): mm: drop the assumption that VM_SHARED always implies writable mm: update memfd seal write check to include F_SEAL_WRITE mm: reinstate ability to map write-sealed memfd mappings read-only selftests/memfd: add test for mapping write-sealed memfd read-only fs/hugetlbfs/inode.c | 2 +- include/linux/fs.h | 4 +- include/linux/memfd.h | 14 ++++ include/linux/mm.h | 80 +++++++++++++++------- kernel/fork.c | 2 +- mm/filemap.c | 2 +- mm/madvise.c | 2 +- mm/memfd.c | 2 +- mm/mmap.c | 10 ++- mm/shmem.c | 2 +- tools/testing/selftests/memfd/memfd_test.c | 43 ++++++++++++ 11 files changed, 129 insertions(+), 34 deletions(-) -- 2.50.1.552.g942d659e1b-goog

4 days, 21 hours

5
16
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2025