Public bug reported:

    SRU Justification

    Impact:
       The upstream process for stable tree updates is quite similar
       in scope to the Ubuntu SRU process, e.g., each patch has to
       demonstrably fix a bug, and each patch is vetted by upstream
       by originating either directly from a mainline/stable Linux tree or
       a minimally backported form of that patch. The following upstream
       stable patches should be included in the Ubuntu kernel:

       v6.1.37 upstream stable release
       from git://git.kernel.org/

            
Linux 6.1.37
xtensa: fix NOMMU build with lock_mm_and_find_vma() conversion
csky: fix up lock_mm_and_find_vma() conversion
parisc: fix expand_stack() conversion
sparc32: fix lock_mm_and_find_vma() conversion
Revert "thermal/drivers/mediatek: Use devm_of_iomap to avoid resource leak in 
mtk_thermal_probe"
HID: logitech-hidpp: add HIDPP_QUIRK_DELAYED_INIT for the T651.
HID: wacom: Use ktime_t rather than int when dealing with timestamps
HID: hidraw: fix data race on device refcount
fbdev: fix potential OOB read in fast_imageblit()
mm: always expand the stack with the mmap write lock held
execve: expand new process stack manually ahead of time
mm: make find_extend_vma() fail if write lock not held
powerpc/mm: convert coprocessor fault to lock_mm_and_find_vma()
mm/fault: convert remaining simple cases to lock_mm_and_find_vma()
arm/mm: Convert to using lock_mm_and_find_vma()
riscv/mm: Convert to using lock_mm_and_find_vma()
mips/mm: Convert to using lock_mm_and_find_vma()
powerpc/mm: Convert to using lock_mm_and_find_vma()
arm64/mm: Convert to using lock_mm_and_find_vma()
mm: make the page fault mmap locking killable
mm: introduce new 'lock_mm_and_find_vma()' page fault helper
maple_tree: fix potential out-of-bounds access in mas_wr_end_piv()
can: isotp: isotp_sendmsg(): fix return error fix on TX path
x86/smp: Cure kexec() vs. mwait_play_dead() breakage
x86/smp: Use dedicated cache-line for mwait_play_dead()
x86/smp: Remove pointless wmb()s from native_stop_other_cpus()
x86/smp: Dont access non-existing CPUID leaf
x86/smp: Make stop_other_cpus() more robust
x86/microcode/AMD: Load late on both threads too
mm, hwpoison: when copy-on-write hits poison, take page offline
mm, hwpoison: try to recover from copy-on write faults
mptcp: ensure listener is unhashed before updating the sk status
mm/mmap: Fix error return in do_vmi_align_munmap()
mm/mmap: Fix error path in do_vmi_align_munmap()

** Affects: linux-oem-6.1 (Ubuntu)
     Importance: Undecided
         Status: Confirmed

** Affects: linux-oem-6.1 (Ubuntu Jammy)
     Importance: Undecided
         Status: New


** Tags: kernel-stable-tracking-bug

** Changed in: linux-oem-6.1 (Ubuntu)
       Status: New => Confirmed

** Tags added: kernel-stable-tracking-bug

** Also affects: linux-oem-6.1 (Ubuntu Jammy)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem-6.1 in Ubuntu.
https://bugs.launchpad.net/bugs/2025713

Title:
  Jammy update: v6.1.37 upstream stable release

Status in linux-oem-6.1 package in Ubuntu:
  Confirmed
Status in linux-oem-6.1 source package in Jammy:
  New

Bug description:
  
      SRU Justification

      Impact:
         The upstream process for stable tree updates is quite similar
         in scope to the Ubuntu SRU process, e.g., each patch has to
         demonstrably fix a bug, and each patch is vetted by upstream
         by originating either directly from a mainline/stable Linux tree or
         a minimally backported form of that patch. The following upstream
         stable patches should be included in the Ubuntu kernel:

         v6.1.37 upstream stable release
         from git://git.kernel.org/

              
  Linux 6.1.37
  xtensa: fix NOMMU build with lock_mm_and_find_vma() conversion
  csky: fix up lock_mm_and_find_vma() conversion
  parisc: fix expand_stack() conversion
  sparc32: fix lock_mm_and_find_vma() conversion
  Revert "thermal/drivers/mediatek: Use devm_of_iomap to avoid resource leak in 
mtk_thermal_probe"
  HID: logitech-hidpp: add HIDPP_QUIRK_DELAYED_INIT for the T651.
  HID: wacom: Use ktime_t rather than int when dealing with timestamps
  HID: hidraw: fix data race on device refcount
  fbdev: fix potential OOB read in fast_imageblit()
  mm: always expand the stack with the mmap write lock held
  execve: expand new process stack manually ahead of time
  mm: make find_extend_vma() fail if write lock not held
  powerpc/mm: convert coprocessor fault to lock_mm_and_find_vma()
  mm/fault: convert remaining simple cases to lock_mm_and_find_vma()
  arm/mm: Convert to using lock_mm_and_find_vma()
  riscv/mm: Convert to using lock_mm_and_find_vma()
  mips/mm: Convert to using lock_mm_and_find_vma()
  powerpc/mm: Convert to using lock_mm_and_find_vma()
  arm64/mm: Convert to using lock_mm_and_find_vma()
  mm: make the page fault mmap locking killable
  mm: introduce new 'lock_mm_and_find_vma()' page fault helper
  maple_tree: fix potential out-of-bounds access in mas_wr_end_piv()
  can: isotp: isotp_sendmsg(): fix return error fix on TX path
  x86/smp: Cure kexec() vs. mwait_play_dead() breakage
  x86/smp: Use dedicated cache-line for mwait_play_dead()
  x86/smp: Remove pointless wmb()s from native_stop_other_cpus()
  x86/smp: Dont access non-existing CPUID leaf
  x86/smp: Make stop_other_cpus() more robust
  x86/microcode/AMD: Load late on both threads too
  mm, hwpoison: when copy-on-write hits poison, take page offline
  mm, hwpoison: try to recover from copy-on write faults
  mptcp: ensure listener is unhashed before updating the sk status
  mm/mmap: Fix error return in do_vmi_align_munmap()
  mm/mmap: Fix error path in do_vmi_align_munmap()

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-oem-6.1/+bug/2025713/+subscriptions


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to