Changelog in Linux kernel 5.10.228

 
ALSA: hda/conexant - Fix audio routing for HP EliteOne 1000 G2 [+ + +]
Author: Vasiliy Kovalev <[email protected]>
Date:   Wed Oct 9 16:42:48 2024 +0300

    ALSA: hda/conexant - Fix audio routing for HP EliteOne 1000 G2
    
    commit 9988844c457f6f17fb2e75aa000b6c3b1b673bb9 upstream.
    
    There is a problem with simultaneous audio output to headphones and
    speakers, and when headphones are turned off, the speakers also turn
    off and do not turn them on.
    
    However, it was found that if you boot linux immediately after windows,
    there are no such problems. When comparing alsa-info, the only difference
    is the different configuration of Node 0x1d:
    
    working conf. (windows): Pin-ctls: 0x80: HP
    not working     (linux): Pin-ctls: 0xc0: OUT HP
    
    This patch disable the AC_PINCTL_OUT_EN bit of Node 0x1d and fixes the
    described problem.
    
    Signed-off-by: Vasiliy Kovalev <[email protected]>
    Cc: <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
ALSA: hda/conexant - Use cached pin control for Node 0x1d on HP EliteOne 1000 G2 [+ + +]
Author: Vasiliy Kovalev <[email protected]>
Date:   Wed Oct 16 11:07:13 2024 +0300

    ALSA: hda/conexant - Use cached pin control for Node 0x1d on HP EliteOne 1000 G2
    
    commit 164cd0e077a18d6208523c82b102c98c77fdd51f upstream.
    
    The cached version avoids redundant commands to the codec, improving
    stability and reducing unnecessary operations. This change ensures
    better power management and reliable restoration of pin configurations,
    especially after hibernation (S4) and other power transitions.
    
    Fixes: 9988844c457f ("ALSA: hda/conexant - Fix audio routing for HP EliteOne 1000 G2")
    Suggested-by: Kai-Heng Feng <[email protected]>
    Suggested-by: Takashi Iwai <[email protected]>
    Signed-off-by: Vasiliy Kovalev <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
arm64: probes: Fix simulate_ldr*_literal() [+ + +]
Author: Mark Rutland <[email protected]>
Date:   Tue Oct 8 16:58:47 2024 +0100

    arm64: probes: Fix simulate_ldr*_literal()
    
    commit 50f813e57601c22b6f26ced3193b9b94d70a2640 upstream.
    
    The simulate_ldr_literal() code always loads a 64-bit quantity, and when
    simulating a 32-bit load into a 'W' register, it discards the most
    significant 32 bits. For big-endian kernels this means that the relevant
    bits are discarded, and the value returned is the the subsequent 32 bits
    in memory (i.e. the value at addr + 4).
    
    Additionally, simulate_ldr_literal() and simulate_ldrsw_literal() use a
    plain C load, which the compiler may tear or elide (e.g. if the target
    is the zero register). Today this doesn't happen to matter, but it may
    matter in future if trampoline code uses a LDR (literal) or LDRSW
    (literal).
    
    Update simulate_ldr_literal() and simulate_ldrsw_literal() to use an
    appropriately-sized READ_ONCE() to perform the access, which avoids
    these problems.
    
    Fixes: 39a67d49ba35 ("arm64: kprobes instruction simulation support")
    Cc: [email protected]
    Signed-off-by: Mark Rutland <[email protected]>
    Cc: Catalin Marinas <[email protected]>
    Cc: Will Deacon <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

arm64: probes: Remove broken LDR (literal) uprobe support [+ + +]
Author: Mark Rutland <[email protected]>
Date:   Tue Oct 8 16:58:46 2024 +0100

    arm64: probes: Remove broken LDR (literal) uprobe support
    
    commit acc450aa07099d071b18174c22a1119c57da8227 upstream.
    
    The simulate_ldr_literal() and simulate_ldrsw_literal() functions are
    unsafe to use for uprobes. Both functions were originally written for
    use with kprobes, and access memory with plain C accesses. When uprobes
    was added, these were reused unmodified even though they cannot safely
    access user memory.
    
    There are three key problems:
    
    1) The plain C accesses do not have corresponding extable entries, and
       thus if they encounter a fault the kernel will treat these as
       unintentional accesses to user memory, resulting in a BUG() which
       will kill the kernel thread, and likely lead to further issues (e.g.
       lockup or panic()).
    
    2) The plain C accesses are subject to HW PAN and SW PAN, and so when
       either is in use, any attempt to simulate an access to user memory
       will fault. Thus neither simulate_ldr_literal() nor
       simulate_ldrsw_literal() can do anything useful when simulating a
       user instruction on any system with HW PAN or SW PAN.
    
    3) The plain C accesses are privileged, as they run in kernel context,
       and in practice can access a small range of kernel virtual addresses.
       The instructions they simulate have a range of +/-1MiB, and since the
       simulated instructions must itself be a user instructions in the
       TTBR0 address range, these can address the final 1MiB of the TTBR1
       acddress range by wrapping downwards from an address in the first
       1MiB of the TTBR0 address range.
    
       In contemporary kernels the last 8MiB of TTBR1 address range is
       reserved, and accesses to this will always fault, meaning this is no
       worse than (1).
    
       Historically, it was theoretically possible for the linear map or
       vmemmap to spill into the final 8MiB of the TTBR1 address range, but
       in practice this is extremely unlikely to occur as this would
       require either:
    
       * Having enough physical memory to fill the entire linear map all the
         way to the final 1MiB of the TTBR1 address range.
    
       * Getting unlucky with KASLR randomization of the linear map such
         that the populated region happens to overlap with the last 1MiB of
         the TTBR address range.
    
       ... and in either case if we were to spill into the final page there
       would be larger problems as the final page would alias with error
       pointers.
    
    Practically speaking, (1) and (2) are the big issues. Given there have
    been no reports of problems since the broken code was introduced, it
    appears that no-one is relying on probing these instructions with
    uprobes.
    
    Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW
    (literal), limiting the use of simulate_ldr_literal() and
    simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR
    (literal) and LDRSW (literal) will be rejected as
    arm_probe_decode_insn() will return INSN_REJECTED. In future we can
    consider introducing working uprobes support for these instructions, but
    this will require more significant work.
    
    Fixes: 9842ceae9fa8 ("arm64: Add uprobe support")
    Cc: [email protected]
    Signed-off-by: Mark Rutland <[email protected]>
    Cc: Catalin Marinas <[email protected]>
    Cc: Will Deacon <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Will Deacon <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race [+ + +]
Author: Omar Sandoval <[email protected]>
Date:   Tue Oct 15 10:59:46 2024 -0700

    blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race
    
    commit e972b08b91ef48488bae9789f03cfedb148667fb upstream.
    
    We're seeing crashes from rq_qos_wake_function that look like this:
    
      BUG: unable to handle page fault for address: ffffafe180a40084
      #PF: supervisor write access in kernel mode
      #PF: error_code(0x0002) - not-present page
      PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0
      Oops: Oops: 0002 [#1] PREEMPT SMP PTI
      CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
      RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40
      Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00
      RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046
      RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011
      RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084
      RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011
      R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002
      R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003
      FS:  0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      PKRU: 55555554
      Call Trace:
       <IRQ>
       try_to_wake_up+0x5a/0x6a0
       rq_qos_wake_function+0x71/0x80
       __wake_up_common+0x75/0xa0
       __wake_up+0x36/0x60
       scale_up.part.0+0x50/0x110
       wb_timer_fn+0x227/0x450
       ...
    
    So rq_qos_wake_function() calls wake_up_process(data->task), which calls
    try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock).
    
    p comes from data->task, and data comes from the waitqueue entry, which
    is stored on the waiter's stack in rq_qos_wait(). Analyzing the core
    dump with drgn, I found that the waiter had already woken up and moved
    on to a completely unrelated code path, clobbering what was previously
    data->task. Meanwhile, the waker was passing the clobbered garbage in
    data->task to wake_up_process(), leading to the crash.
    
    What's happening is that in between rq_qos_wake_function() deleting the
    waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding
    that it already got a token and returning. The race looks like this:
    
    rq_qos_wait()                           rq_qos_wake_function()
    ==============================================================
    prepare_to_wait_exclusive()
                                            data->got_token = true;
                                            list_del_init(&curr->entry);
    if (data.got_token)
            break;
    finish_wait(&rqw->wait, &data.wq);
      ^- returns immediately because
         list_empty_careful(&wq_entry->entry)
         is true
    ... return, go do something else ...
                                            wake_up_process(data->task)
                                              (NO LONGER VALID!)-^
    
    Normally, finish_wait() is supposed to synchronize against the waker.
    But, as noted above, it is returning immediately because the waitqueue
    entry has already been removed from the waitqueue.
    
    The bug is that rq_qos_wake_function() is accessing the waitqueue entry
    AFTER deleting it. Note that autoremove_wake_function() wakes the waiter
    and THEN deletes the waitqueue entry, which is the proper order.
    
    Fix it by swapping the order. We also need to use
    list_del_init_careful() to match the list_empty_careful() in
    finish_wait().
    
    Fixes: 38cfb5a45ee0 ("blk-wbt: improve waking of tasks")
    Cc: [email protected]
    Signed-off-by: Omar Sandoval <[email protected]>
    Acked-by: Tejun Heo <[email protected]>
    Reviewed-by: Johannes Thumshirn <[email protected]>
    Link: https://lore.kernel.org/r/d3bee2463a67b1ee597211823bf7ad3721c26e41.1729014591.git.osandov@fb.com
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001 [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Wed Oct 16 11:47:00 2024 -0400

    Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001
    
    commit 2c1dda2acc4192d826e84008d963b528e24d12bc upstream.
    
    Fake CSR controllers don't seem to handle short-transfer properly which
    cause command to time out:
    
    kernel: usb 1-1: new full-speed USB device number 19 using xhci_hcd
    kernel: usb 1-1: New USB device found, idVendor=0a12, idProduct=0001, bcdDevice=88.91
    kernel: usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
    kernel: usb 1-1: Product: BT DONGLE10
    ...
    Bluetooth: hci1: Opcode 0x1004 failed: -110
    kernel: Bluetooth: hci1: command 0x1004 tx timeout
    
    According to USB Spec 2.0 Section 5.7.3 Interrupt Transfer Packet Size
    Constraints a interrupt transfer is considered complete when the size is 0
    (ZPL) or < wMaxPacketSize:
    
     'When an interrupt transfer involves more data than can fit in one
     data payload of the currently established maximum size, all data
     payloads are required to be maximum-sized except for the last data
     payload, which will contain the remaining data. An interrupt transfer
     is complete when the endpoint does one of the following:
    
     • Has transferred exactly the amount of data expected
     • Transfers a packet with a payload size less than wMaxPacketSize or
     transfers a zero-length packet'
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=219365
    Fixes: 7b05933340f4 ("Bluetooth: btusb: Fix not handling ZPL/short-transfer")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

Bluetooth: Remove debugfs directory on module init failure [+ + +]
Author: Aaron Thompson <[email protected]>
Date:   Fri Oct 4 23:04:10 2024 +0000

    Bluetooth: Remove debugfs directory on module init failure
    
    commit 1db4564f101b47188c1b71696bd342ef09172b22 upstream.
    
    If bt_init() fails, the debugfs directory currently is not removed. If
    the module is loaded again after that, the debugfs directory is not set
    up properly due to the existing directory.
    
      # modprobe bluetooth
      # ls -laF /sys/kernel/debug/bluetooth
      total 0
      drwxr-xr-x  2 root root 0 Sep 27 14:26 ./
      drwx------ 31 root root 0 Sep 27 14:25 ../
      -r--r--r--  1 root root 0 Sep 27 14:26 l2cap
      -r--r--r--  1 root root 0 Sep 27 14:26 sco
      # modprobe -r bluetooth
      # ls -laF /sys/kernel/debug/bluetooth
      ls: cannot access '/sys/kernel/debug/bluetooth': No such file or directory
      #
    
      # modprobe bluetooth
      modprobe: ERROR: could not insert 'bluetooth': Invalid argument
      # dmesg | tail -n 6
      Bluetooth: Core ver 2.22
      NET: Registered PF_BLUETOOTH protocol family
      Bluetooth: HCI device and connection manager initialized
      Bluetooth: HCI socket layer initialized
      Bluetooth: Faking l2cap_init() failure for testing
      NET: Unregistered PF_BLUETOOTH protocol family
      # ls -laF /sys/kernel/debug/bluetooth
      total 0
      drwxr-xr-x  2 root root 0 Sep 27 14:31 ./
      drwx------ 31 root root 0 Sep 27 14:26 ../
      #
    
      # modprobe bluetooth
      # dmesg | tail -n 7
      Bluetooth: Core ver 2.22
      debugfs: Directory 'bluetooth' with parent '/' already present!
      NET: Registered PF_BLUETOOTH protocol family
      Bluetooth: HCI device and connection manager initialized
      Bluetooth: HCI socket layer initialized
      Bluetooth: L2CAP socket layer initialized
      Bluetooth: SCO socket layer initialized
      # ls -laF /sys/kernel/debug/bluetooth
      total 0
      drwxr-xr-x  2 root root 0 Sep 27 14:31 ./
      drwx------ 31 root root 0 Sep 27 14:26 ../
      #
    
    Cc: [email protected]
    Fixes: ffcecac6a738 ("Bluetooth: Create root debugfs directory during module init")
    Signed-off-by: Aaron Thompson <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/radeon: Fix encoder->possible_clones [+ + +]
Author: Ville Syrjälä <[email protected]>
Date:   Mon Oct 14 19:09:36 2024 +0300

    drm/radeon: Fix encoder->possible_clones
    
    commit 28127dba64d8ae1a0b737b973d6d029908599611 upstream.
    
    Include the encoder itself in its possible_clones bitmask.
    In the past nothing validated that drivers were populating
    possible_clones correctly, but that changed in commit
    74d2aacbe840 ("drm: Validate encoder->possible_clones").
    Looks like radeon never got the memo and is still not
    following the rules 100% correctly.
    
    This results in some warnings during driver initialization:
    Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7)
    WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c
    ...
    
    Cc: Alex Deucher <[email protected]>
    Cc: [email protected]
    Fixes: 74d2aacbe840 ("drm: Validate encoder->possible_clones")
    Reported-by: Erhard Furtner <[email protected]>
    Closes: https://lore.kernel.org/dri-devel/20241009000321.418e4294@yea/
    Tested-by: Erhard Furtner <[email protected]>
    Signed-off-by: Ville Syrjälä <[email protected]>
    Signed-off-by: Alex Deucher <[email protected]>
    (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/vmwgfx: Handle surface check failure correctly [+ + +]
Author: Nikolay Kuratov <[email protected]>
Date:   Wed Oct 2 15:24:29 2024 +0300

    drm/vmwgfx: Handle surface check failure correctly
    
    commit 26498b8d54373d31a621d7dec95c4bd842563b3b upstream.
    
    Currently if condition (!bo and !vmw_kms_srf_ok()) was met
    we go to err_out with ret == 0.
    err_out dereferences vfb if ret == 0, but in our case vfb is still NULL.
    
    Fix this by assigning sensible error to ret.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE
    
    Signed-off-by: Nikolay Kuratov <[email protected]>
    Cc: [email protected]
    Fixes: 810b3e1683d0 ("drm/vmwgfx: Support topology greater than texture size")
    Signed-off-by: Zack Rusin <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
fat: fix uninitialized variable [+ + +]
Author: OGAWA Hirofumi <[email protected]>
Date:   Fri Oct 4 15:03:49 2024 +0900

    fat: fix uninitialized variable
    
    commit 963a7f4d3b90ee195b895ca06b95757fcba02d1a upstream.
    
    syszbot produced this with a corrupted fs image.  In theory, however an IO
    error would trigger this also.
    
    This affects just an error report, so should not be a serious error.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: OGAWA Hirofumi <[email protected]>
    Reported-by: [email protected]
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
iio: adc: ti-ads124s08: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Thu Oct 3 23:04:49 2024 +0200

    iio: adc: ti-ads124s08: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig
    
    commit eb143d05def52bc6d193e813018e5fa1a0e47c77 upstream.
    
    This driver makes use of triggered buffers, but does not select the
    required modules.
    
    Add the missing 'select IIO_BUFFER' and 'select IIO_TRIGGERED_BUFFER'.
    
    Fixes: e717f8c6dfec ("iio: adc: Add the TI ads124s08 ADC code")
    Signed-off-by: Javier Carrasco <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Thu Oct 3 23:04:50 2024 +0200

    iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig
    
    commit 4c4834fd8696a949d1b1f1c2c5b96e1ad2083b02 upstream.
    
    This driver makes use of triggered buffers, but does not select the
    required modules.
    
    Fixes: 2a86487786b5 ("iio: adc: ti-ads8688: add trigger and buffer support")
    Add the missing 'select IIO_BUFFER' and 'select IIO_TRIGGERED_BUFFER'.
    
    Signed-off-by: Javier Carrasco <[email protected]>
    Reviewed-by: Sean Nyekjaer <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: dac: ad5770r: add missing select REGMAP_SPI in Kconfig [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Thu Oct 3 18:49:38 2024 +0200

    iio: dac: ad5770r: add missing select REGMAP_SPI in Kconfig
    
    commit bcdab6f74c91cda19714354fd4e9e3ef3c9a78b3 upstream.
    
    This driver makes use of regmap_spi, but does not select the required
    module.
    Add the missing 'select REGMAP_SPI'.
    
    Fixes: cbbb819837f6 ("iio: dac: ad5770r: Add AD5770R support")
    Signed-off-by: Javier Carrasco <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Thu Oct 3 18:49:39 2024 +0200

    iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig
    
    commit 252ff06a4cb4e572cb3c7fcfa697db96b08a7781 upstream.
    
    This driver makes use of regmap_spi, but does not select the required
    module.
    Add the missing 'select REGMAP_SPI'.
    
    Fixes: 8316cebd1e59 ("iio: dac: add support for ltc1660")
    Signed-off-by: Javier Carrasco <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in Kconfig [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Thu Oct 3 18:49:40 2024 +0200

    iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in Kconfig
    
    commit 27b6aa68a68105086aef9f0cb541cd688e5edea8 upstream.
    
    This driver makes use of regmap_mmio, but does not select the required
    module.
    Add the missing 'select REGMAP_MMIO'.
    
    Fixes: 4d4b30526eb8 ("iio: dac: add support for stm32 DAC")
    Signed-off-by: Javier Carrasco <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: hid-sensors: Fix an error handling path in _hid_sensor_set_report_latency() [+ + +]
Author: Christophe JAILLET <[email protected]>
Date:   Thu Oct 3 20:41:12 2024 +0200

    iio: hid-sensors: Fix an error handling path in _hid_sensor_set_report_latency()
    
    commit 3a29b84cf7fbf912a6ab1b9c886746f02b74ea25 upstream.
    
    If hid_sensor_set_report_latency() fails, the error code should be returned
    instead of a value likely to be interpreted as 'success'.
    
    Fixes: 138bc7969c24 ("iio: hid-sensor-hub: Implement batch mode")
    Signed-off-by: Christophe JAILLET <[email protected]>
    Acked-by: Srinivas Pandruvada <[email protected]>
    Link: https://patch.msgid.link/c50640665f091a04086e5092cf50f73f2055107a.1727980825.git.christophe.jaillet@wanadoo.fr
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: light: opt3001: add missing full-scale range value [+ + +]
Author: Emil Gedenryd <[email protected]>
Date:   Fri Sep 13 11:57:02 2024 +0200

    iio: light: opt3001: add missing full-scale range value
    
    commit 530688e39c644543b71bdd9cb45fdfb458a28eaa upstream.
    
    The opt3001 driver uses predetermined full-scale range values to
    determine what exponent to use for event trigger threshold values.
    The problem is that one of the values specified in the datasheet is
    missing from the implementation. This causes larger values to be
    scaled down to an incorrect exponent, effectively reducing the
    maximum settable threshold value by a factor of 2.
    
    Add missing full-scale range array value.
    
    Fixes: 94a9b7b1809f ("iio: light: add support for TI's opt3001 light sensor")
    Signed-off-by: Emil Gedenryd <[email protected]>
    Cc: <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: light: veml6030: fix ALS sensor resolution [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Mon Sep 23 00:17:49 2024 +0200

    iio: light: veml6030: fix ALS sensor resolution
    
    commit c9e9746f275c45108f2b0633a4855d65d9ae0736 upstream.
    
    The driver still uses the sensor resolution provided in the datasheet
    until Rev. 1.6, 28-Apr-2022, which was updated with Rev 1.7,
    28-Nov-2023. The original ambient light resolution has been updated from
    0.0036 lx/ct to 0.0042 lx/ct, which is the value that can be found in
    the current device datasheet.
    
    Update the default resolution for IT = 100 ms and GAIN = 1/8 from the
    original 4608 mlux/cnt to the current value from the "Resolution and
    maximum detection range" table (Application Note 84367, page 5), 5376
    mlux/cnt.
    
    Cc: <[email protected]>
    Fixes: 7b779f573c48 ("iio: light: add driver for veml6030 ambient light sensor")
    Signed-off-by: Javier Carrasco <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: light: veml6030: fix IIO device retrieval from embedded device [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Fri Sep 13 15:18:58 2024 +0200

    iio: light: veml6030: fix IIO device retrieval from embedded device
    
    commit c7c44e57750c31de43906d97813273fdffcf7d02 upstream.
    
    The dev pointer that is received as an argument in the
    in_illuminance_period_available_show function references the device
    embedded in the IIO device, not in the i2c client.
    
    dev_to_iio_dev() must be used to accessthe right data. The current
    implementation leads to a segmentation fault on every attempt to read
    the attribute because indio_dev gets a NULL assignment.
    
    This bug has been present since the first appearance of the driver,
    apparently since the last version (V6) before getting applied. A
    constant attribute was used until then, and the last modifications might
    have not been tested again.
    
    Cc: [email protected]
    Fixes: 7b779f573c48 ("iio: light: add driver for veml6030 ambient light sensor")
    Signed-off-by: Javier Carrasco <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

iio: proximity: mb1232: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig [+ + +]
Author: Javier Carrasco <[email protected]>
Date:   Thu Oct 3 23:04:59 2024 +0200

    iio: proximity: mb1232: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig
    
    commit 75461a0b15d7c026924d0001abce0476bbc7eda8 upstream.
    
    This driver makes use of triggered buffers, but does not select the
    required modules.
    
    Add the missing 'select IIO_BUFFER' and 'select IIO_TRIGGERED_BUFFER'.
    
    Fixes: 16b05261537e ("mb1232.c: add distance iio sensor with i2c")
    Signed-off-by: Javier Carrasco <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Cc: <[email protected]>
    Signed-off-by: Jonathan Cameron <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
io_uring/sqpoll: close race on waiting for sqring entries [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Tue Oct 15 08:58:25 2024 -0600

    io_uring/sqpoll: close race on waiting for sqring entries
    
    commit 28aabffae6be54284869a91cd8bccd3720041129 upstream.
    
    When an application uses SQPOLL, it must wait for the SQPOLL thread to
    consume SQE entries, if it fails to get an sqe when calling
    io_uring_get_sqe(). It can do so by calling io_uring_enter(2) with the
    flag value of IORING_ENTER_SQ_WAIT. In liburing, this is generally done
    with io_uring_sqring_wait(). There's a natural expectation that once
    this call returns, a new SQE entry can be retrieved, filled out, and
    submitted. However, the kernel uses the cached sq head to determine if
    the SQRING is full or not. If the SQPOLL thread is currently in the
    process of submitting SQE entries, it may have updated the cached sq
    head, but not yet committed it to the SQ ring. Hence the kernel may find
    that there are SQE entries ready to be consumed, and return successfully
    to the application. If the SQPOLL thread hasn't yet committed the SQ
    ring entries by the time the application returns to userspace and
    attempts to get a new SQE, it will fail getting a new SQE.
    
    Fix this by having io_sqring_full() always use the user visible SQ ring
    head entry, rather than the internally cached one.
    
    Cc: [email protected] # 5.10+
    Link: https://github.com/axboe/liburing/discussions/1267
    Reported-by: Benedek Thaler <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

io_uring/sqpoll: do not allow pinning outside of cpuset [+ + +]
Author: Felix Moessbauer <[email protected]>
Date:   Thu Oct 17 13:50:27 2024 +0200

    io_uring/sqpoll: do not allow pinning outside of cpuset
    
    commit f011c9cf04c06f16b24f583d313d3c012e589e50 upstream.
    
    The submit queue polling threads are userland threads that just never
    exit to the userland. When creating the thread with IORING_SETUP_SQ_AFF,
    the affinity of the poller thread is set to the cpu specified in
    sq_thread_cpu. However, this CPU can be outside of the cpuset defined
    by the cgroup cpuset controller. This violates the rules defined by the
    cpuset controller and is a potential issue for realtime applications.
    
    In b7ed6d8ffd6 we fixed the default affinity of the poller thread, in
    case no explicit pinning is required by inheriting the one of the
    creating task. In case of explicit pinning, the check is more
    complicated, as also a cpu outside of the parent cpumask is allowed.
    We implemented this by using cpuset_cpus_allowed (that has support for
    cgroup cpusets) and testing if the requested cpu is in the set.
    
    Fixes: 37d1e2e3642e ("io_uring: move SQPOLL thread io-wq forked worker")
    Signed-off-by: Felix Moessbauer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

io_uring/sqpoll: do not put cpumask on stack [+ + +]
Author: Felix Moessbauer <[email protected]>
Date:   Thu Oct 17 13:50:29 2024 +0200

    io_uring/sqpoll: do not put cpumask on stack
    
    commit 7f44beadcc11adb98220556d2ddbe9c97aa6d42d upstream.
    
    Putting the cpumask on the stack is deprecated for a long time (since
    2d3854a37e8), as these can be big. Given that, change the on-stack
    allocation of allowed_mask to be dynamically allocated.
    
    Fixes: f011c9cf04c0 ("io_uring/sqpoll: do not allow pinning outside of cpuset")
    Signed-off-by: Felix Moessbauer <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

io_uring/sqpoll: retain test for whether the CPU is valid [+ + +]
Author: Jens Axboe <[email protected]>
Date:   Thu Oct 17 13:50:28 2024 +0200

    io_uring/sqpoll: retain test for whether the CPU is valid
    
    commit a09c17240bdf2e9fa6d0591afa9448b59785f7d4 upstream.
    
    A recent commit ensured that SQPOLL cannot be setup with a CPU that
    isn't in the current tasks cpuset, but it also dropped testing whether
    the CPU is valid in the first place. Without that, if a task passes in
    a CPU value that is too high, the following KASAN splat can get
    triggered:
    
    BUG: KASAN: stack-out-of-bounds in io_sq_offload_create+0x858/0xaa4
    Read of size 8 at addr ffff800089bc7b90 by task wq-aff.t/1391
    
    CPU: 4 UID: 1000 PID: 1391 Comm: wq-aff.t Not tainted 6.11.0-rc7-00227-g371c468f4db6 #7080
    Hardware name: linux,dummy-virt (DT)
    Call trace:
     dump_backtrace.part.0+0xcc/0xe0
     show_stack+0x14/0x1c
     dump_stack_lvl+0x58/0x74
     print_report+0x16c/0x4c8
     kasan_report+0x9c/0xe4
     __asan_report_load8_noabort+0x1c/0x24
     io_sq_offload_create+0x858/0xaa4
     io_uring_setup+0x1394/0x17c4
     __arm64_sys_io_uring_setup+0x6c/0x180
     invoke_syscall+0x6c/0x260
     el0_svc_common.constprop.0+0x158/0x224
     do_el0_svc+0x3c/0x5c
     el0_svc+0x34/0x70
     el0t_64_sync_handler+0x118/0x124
     el0t_64_sync+0x168/0x16c
    
    The buggy address belongs to stack of task wq-aff.t/1391
     and is located at offset 48 in frame:
     io_sq_offload_create+0x0/0xaa4
    
    This frame has 1 object:
     [32, 40) 'allowed_mask'
    
    The buggy address belongs to the virtual mapping at
     [ffff800089bc0000, ffff800089bc9000) created by:
     kernel_clone+0x124/0x7e0
    
    The buggy address belongs to the physical page:
    page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff0000d740af80 pfn:0x11740a
    memcg:ffff0000c2706f02
    flags: 0xbffe00000000000(node=0|zone=2|lastcpupid=0x1fff)
    raw: 0bffe00000000000 0000000000000000 dead000000000122 0000000000000000
    raw: ffff0000d740af80 0000000000000000 00000001ffffffff ffff0000c2706f02
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff800089bc7a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     ffff800089bc7b00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
    >ffff800089bc7b80: 00 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
                             ^
     ffff800089bc7c00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
     ffff800089bc7c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3
    
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-lkp/[email protected]
    Fixes: f011c9cf04c0 ("io_uring/sqpoll: do not allow pinning outside of cpuset")
    Tested-by: Felix Moessbauer <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Felix Moessbauer <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
irqchip/gic-v3-its: Fix VSYNC referencing an unmapped VPE on GIC v4.1 [+ + +]
Author: Nianyao Tang <[email protected]>
Date:   Sat Apr 6 02:27:37 2024 +0000

    irqchip/gic-v3-its: Fix VSYNC referencing an unmapped VPE on GIC v4.1
    
    commit 80e9963fb3b5509dfcabe9652d56bf4b35542055 upstream.
    
    As per the GICv4.1 spec (Arm IHI 0069H, 5.3.19):
    
     "A VMAPP with {V, Alloc}=={0, x} is self-synchronizing, This means the ITS
      command queue does not show the command as consumed until all of its
      effects are completed."
    
    Furthermore, VSYNC is allowed to deliver an SError when referencing a
    non existent VPE.
    
    By these definitions, a VMAPP followed by a VSYNC is a bug, as the
    later references a VPE that has been unmapped by the former.
    
    Fix it by eliding the VSYNC in this scenario.
    
    Fixes: 64edfaa9a234 ("irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP")
    Signed-off-by: Nianyao Tang <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Marc Zyngier <[email protected]>
    Reviewed-by: Zenghui Yu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
irqchip/gic-v4: Don't allow a VMOVP on a dying VPE [+ + +]
Author: Marc Zyngier <[email protected]>
Date:   Wed Oct 2 21:49:59 2024 +0100

    irqchip/gic-v4: Don't allow a VMOVP on a dying VPE
    
    commit 1442ee0011983f0c5c4b92380e6853afb513841a upstream.
    
    Kunkun Jiang reported that there is a small window of opportunity for
    userspace to force a change of affinity for a VPE while the VPE has already
    been unmapped, but the corresponding doorbell interrupt still visible in
    /proc/irq/.
    
    Plug the race by checking the value of vmapp_count, which tracks whether
    the VPE is mapped ot not, and returning an error in this case.
    
    This involves making vmapp_count common to both GICv4.1 and its v4.0
    ancestor.
    
    Fixes: 64edfaa9a234 ("irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP")
    Reported-by: Kunkun Jiang <[email protected]>
    Signed-off-by: Marc Zyngier <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Link: https://lore.kernel.org/all/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin() [+ + +]
Author: Breno Leitao <[email protected]>
Date:   Fri May 10 02:23:52 2024 -0700

    KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()
    
    commit 49f683b41f28918df3e51ddc0d928cb2e934ccdb upstream.
    
    Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure the
    loads and stores are atomic.  In the extremely unlikely scenario the
    compiler tears the stores, it's theoretically possible for KVM to attempt
    to get a vCPU using an out-of-bounds index, e.g. if the write is split
    into multiple 8-bit stores, and is paired with a 32-bit load on a VM with
    257 vCPUs:
    
      CPU0                              CPU1
      last_boosted_vcpu = 0xff;
    
                                        (last_boosted_vcpu = 0x100)
                                        last_boosted_vcpu[15:8] = 0x01;
      i = (last_boosted_vcpu = 0x1ff)
                                        last_boosted_vcpu[7:0] = 0x00;
    
      vcpu = kvm->vcpu_array[0x1ff];
    
    As detected by KCSAN:
    
      BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]
    
      write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:
      kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm
      handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
      vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
                     arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
      vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
      kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
      kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
      __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
      __x64_sys_ioctl (fs/ioctl.c:890)
      x64_sys_call (arch/x86/entry/syscall_64.c:33)
      do_syscall_64 (arch/x86/entry/common.c:?)
      entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    
      read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4:
      kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm
      handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
      vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
                            arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
      vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
      kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
      kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
      __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
      __x64_sys_ioctl (fs/ioctl.c:890)
      x64_sys_call (arch/x86/entry/syscall_64.c:33)
      do_syscall_64 (arch/x86/entry/common.c:?)
      entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
    
      value changed: 0x00000012 -> 0x00000000
    
    Fixes: 217ece6129f2 ("KVM: use yield_to instead of sleep in kvm_vcpu_on_spin")
    Cc: [email protected]
    Signed-off-by: Breno Leitao <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sean Christopherson <[email protected]>
    Signed-off-by: Saeed Mirzamohammadi <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

KVM: s390: Change virtual to physical address access in diag 0x258 handler [+ + +]
Author: Michael Mueller <[email protected]>
Date:   Tue Sep 17 17:18:34 2024 +0200

    KVM: s390: Change virtual to physical address access in diag 0x258 handler
    
    commit cad4b3d4ab1f062708fff33f44d246853f51e966 upstream.
    
    The parameters for the diag 0x258 are real addresses, not virtual, but
    KVM was using them as virtual addresses. This only happened to work, since
    the Linux kernel as a guest used to have a 1:1 mapping for physical vs
    virtual addresses.
    
    Fix KVM so that it correctly uses the addresses as real addresses.
    
    Cc: [email protected]
    Fixes: 8ae04b8f500b ("KVM: s390: Guest's memory access functions get access registers")
    Suggested-by: Vasily Gorbik <[email protected]>
    Signed-off-by: Michael Mueller <[email protected]>
    Signed-off-by: Nico Boehr <[email protected]>
    Reviewed-by: Christian Borntraeger <[email protected]>
    Reviewed-by: Heiko Carstens <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Acked-by: Janosch Frank <[email protected]>
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: Linux 5.10.228 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Tue Oct 22 15:39:30 2024 +0200

    Linux 5.10.228
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Pavel Machek (CIP) <[email protected]>
    Tested-by: Mark Brown <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/swapfile: skip HugeTLB pages for unuse_vma [+ + +]
Author: Liu Shixin <[email protected]>
Date:   Tue Oct 15 09:45:21 2024 +0800

    mm/swapfile: skip HugeTLB pages for unuse_vma
    
    commit 7528c4fb1237512ee18049f852f014eba80bbe8d upstream.
    
    I got a bad pud error and lost a 1GB HugeTLB when calling swapoff.  The
    problem can be reproduced by the following steps:
    
     1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory.
     2. Swapout the above anonymous memory.
     3. run swapoff and we will get a bad pud error in kernel message:
    
      mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7)
    
    We can tell that pud_clear_bad is called by pud_none_or_clear_bad in
    unuse_pud_range() by ftrace.  And therefore the HugeTLB pages will never
    be freed because we lost it from page table.  We can skip HugeTLB pages
    for unuse_vma to fix it.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 0fe6e20b9c4c ("hugetlb, rmap: add reverse mapping for hugepage")
    Signed-off-by: Liu Shixin <[email protected]>
    Acked-by: Muchun Song <[email protected]>
    Cc: Naoya Horiguchi <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mptcp: handle consistently DSS corruption [+ + +]
Author: Paolo Abeni <[email protected]>
Date:   Sat Oct 19 12:29:08 2024 +0200

    mptcp: handle consistently DSS corruption
    
    commit e32d262c89e2b22cb0640223f953b548617ed8a6 upstream.
    
    Bugged peer implementation can send corrupted DSS options, consistently
    hitting a few warning in the data path. Use DEBUG_NET assertions, to
    avoid the splat on some builds and handle consistently the error, dumping
    related MIBs and performing fallback and/or reset according to the
    subflow type.
    
    Fixes: 6771bfd9ee24 ("mptcp: update mptcp ack sequence from work queue")
    Cc: [email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Reviewed-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    [ Conflicts in mib.[ch], because commit 104125b82e5c ("mptcp: add mib
      for infinite map sending") is linked to a new feature, not available
      in this version. Resolving the conflicts is easy, simply adding the
      new lines declaring the new "DSS corruptions" MIB entries.
      Also removed in protocol.c and subflow.c all DEBUG_NET_WARN_ON_ONCE
      because they are not defined in this version: enough with the MIB
      counters that have been added in this commit. ]
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

mptcp: track and update contiguous data status [+ + +]
Author: Geliang Tang <[email protected]>
Date:   Sat Oct 19 12:29:07 2024 +0200

    mptcp: track and update contiguous data status
    
    commit 0530020a7c8f2204e784f0dbdc882bbd961fdbde upstream.
    
    This patch adds a new member allow_infinite_fallback in mptcp_sock,
    which is initialized to 'true' when the connection begins and is set
    to 'false' on any retransmit or successful MP_JOIN. Only do infinite
    mapping fallback if there is a single subflow AND there have been no
    retransmissions AND there have never been any MP_JOINs.
    
    Suggested-by: Paolo Abeni <[email protected]>
    Signed-off-by: Geliang Tang <[email protected]>
    Signed-off-by: Mat Martineau <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>
    Stable-dep-of: e32d262c89e2 ("mptcp: handle consistently DSS corruption")
    [ Conflicts in protocol.c, because commit 3e5014909b56 ("mptcp: cleanup
      MPJ subflow list handling") is not in this version. This commit is
      linked to a new feature, changing the context around. The new line
      can still be added at the same place.
      Conflicts in protocol.h, because commit 4f6e14bd19d6 ("mptcp: support
      TCP_CORK and TCP_NODELAY") is not in this version. This commit is
      linked to a new feature, changing the context around. The new line can
      still be added at the same place.
      Conflicts in subflow.c, because commit 0348c690ed37 ("mptcp: add the
      fallback check") is not in this version. This commit is linked to a
      new feature, changing the context around. The new line can still be
      added at the same place.
      Extra conflicts in v5.10, because the context has been changed. ]
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
net: enetc: add missing static descriptor and inline keyword [+ + +]
Author: Wei Fang <[email protected]>
Date:   Fri Oct 11 11:01:03 2024 +0800

    net: enetc: add missing static descriptor and inline keyword
    
    commit 1d7b2ce43d2c22a21dadaf689cb36a69570346a6 upstream.
    
    Fix the build warnings when CONFIG_FSL_ENETC_MDIO is not enabled.
    The detailed warnings are shown as follows.
    
    include/linux/fsl/enetc_mdio.h:62:18: warning: no previous prototype for function 'enetc_hw_alloc' [-Wmissing-prototypes]
          62 | struct enetc_hw *enetc_hw_alloc(struct device *dev, void __iomem *port_regs)
             |                  ^
    include/linux/fsl/enetc_mdio.h:62:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
          62 | struct enetc_hw *enetc_hw_alloc(struct device *dev, void __iomem *port_regs)
             | ^
             | static
    8 warnings generated.
    
    Fixes: 6517798dd343 ("enetc: Make MDIO accessors more generic and export to include/linux/fsl")
    Cc: [email protected]
    Reported-by: kernel test robot <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Signed-off-by: Wei Fang <[email protected]>
    Reviewed-by: Claudiu Manoil <[email protected]>
    Reviewed-by: Vladimir Oltean <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-link PHY [+ + +]
Author: Oleksij Rempel <[email protected]>
Date:   Sun Oct 13 07:29:16 2024 +0200

    net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-link PHY
    
    commit d0c3601f2c4e12e7689b0f46ebc17525250ea8c3 upstream.
    
    A boot delay was introduced by commit 79540d133ed6 ("net: macb: Fix
    handling of fixed-link node"). This delay was caused by the call to
    `mdiobus_register()` in cases where a fixed-link PHY was present. The
    MDIO bus registration triggered unnecessary PHY address scans, leading
    to a 20-second delay due to attempts to detect Clause 45 (C45)
    compatible PHYs, despite no MDIO bus being attached.
    
    The commit 79540d133ed6 ("net: macb: Fix handling of fixed-link node")
    was originally introduced to fix a regression caused by commit
    7897b071ac3b4 ("net: macb: convert to phylink"), which caused the driver
    to misinterpret fixed-link nodes as PHY nodes. This resulted in warnings
    like:
    mdio_bus f0028000.ethernet-ffffffff: fixed-link has invalid PHY address
    mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 0
    ...
    mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 31
    
    This patch reworks the logic to avoid registering and allocation of the
    MDIO bus when:
      - The device tree contains a fixed-link node.
      - There is no "mdio" child node in the device tree.
    
    If a child node named "mdio" exists, the MDIO bus will be registered to
    support PHYs  attached to the MACB's MDIO bus. Otherwise, with only a
    fixed-link, the MDIO bus is skipped.
    
    Tested on a sama5d35 based system with a ksz8863 switch attached to
    macb0.
    
    Fixes: 79540d133ed6 ("net: macb: Fix handling of fixed-link node")
    Signed-off-by: Oleksij Rempel <[email protected]>
    Cc: [email protected]
    Reviewed-by: Andrew Lunn <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
nilfs2: propagate directory read errors from nilfs_find_entry() [+ + +]
Author: Ryusuke Konishi <[email protected]>
Date:   Fri Oct 4 12:35:31 2024 +0900

    nilfs2: propagate directory read errors from nilfs_find_entry()
    
    commit 08cfa12adf888db98879dbd735bc741360a34168 upstream.
    
    Syzbot reported that a task hang occurs in vcs_open() during a fuzzing
    test for nilfs2.
    
    The root cause of this problem is that in nilfs_find_entry(), which
    searches for directory entries, ignores errors when loading a directory
    page/folio via nilfs_get_folio() fails.
    
    If the filesystem images is corrupted, and the i_size of the directory
    inode is large, and the directory page/folio is successfully read but
    fails the sanity check, for example when it is zero-filled,
    nilfs_check_folio() may continue to spit out error messages in bursts.
    
    Fix this issue by propagating the error to the callers when loading a
    page/folio fails in nilfs_find_entry().
    
    The current interface of nilfs_find_entry() and its callers is outdated
    and cannot propagate error codes such as -EIO and -ENOMEM returned via
    nilfs_find_entry(), so fix it together.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 2ba466d74ed7 ("nilfs2: directory entry operations")
    Signed-off-by: Ryusuke Konishi <[email protected]>
    Reported-by: Lizhi Xu <[email protected]>
    Closes: https://lkml.kernel.org/r/[email protected]
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=8a192e8d090fa9a31135
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
parport: Proper fix for array out-of-bounds access [+ + +]
Author: Takashi Iwai <[email protected]>
Date:   Fri Sep 20 12:32:19 2024 +0200

    parport: Proper fix for array out-of-bounds access
    
    commit 02ac3a9ef3a18b58d8f3ea2b6e46de657bf6c4f9 upstream.
    
    The recent fix for array out-of-bounds accesses replaced sprintf()
    calls blindly with snprintf().  However, since snprintf() returns the
    would-be-printed size, not the actually output size, the length
    calculation can still go over the given limit.
    
    Use scnprintf() instead of snprintf(), which returns the actually
    output letters, for addressing the potential out-of-bounds access
    properly.
    
    Fixes: ab11dac93d2d ("dev/parport: fix the array out-of-bounds risk")
    Cc: [email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
posix-clock: Fix missing timespec64 check in pc_clock_settime() [+ + +]
Author: Jinjie Ruan <[email protected]>
Date:   Wed Oct 9 15:23:01 2024 +0800

    posix-clock: Fix missing timespec64 check in pc_clock_settime()
    
    commit d8794ac20a299b647ba9958f6d657051fc51a540 upstream.
    
    As Andrew pointed out, it will make sense that the PTP core
    checked timespec64 struct's tv_sec and tv_nsec range before calling
    ptp->info->settime64().
    
    As the man manual of clock_settime() said, if tp.tv_sec is negative or
    tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,
    which include dynamic clocks which handles PTP clock, and the condition is
    consistent with timespec64_valid(). As Thomas suggested, timespec64_valid()
    only check the timespec is valid, but not ensure that the time is
    in a valid range, so check it ahead using timespec64_valid_strict()
    in pc_clock_settime() and return -EINVAL if not valid.
    
    There are some drivers that use tp->tv_sec and tp->tv_nsec directly to
    write registers without validity checks and assume that the higher layer
    has checked it, which is dangerous and will benefit from this, such as
    hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),
    and some drivers can remove the checks of itself.
    
    Cc: [email protected]
    Fixes: 0606f422b453 ("posix clocks: Introduce dynamic clocks")
    Acked-by: Richard Cochran <[email protected]>
    Suggested-by: Andrew Lunn <[email protected]>
    Suggested-by: Thomas Gleixner <[email protected]>
    Signed-off-by: Jinjie Ruan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
powerpc/mm: Always update max/min_low_pfn in mem_topology_setup() [+ + +]
Author: Aneesh Kumar K.V <[email protected]>
Date:   Mon Jul 4 12:08:51 2022 +0530

    powerpc/mm: Always update max/min_low_pfn in mem_topology_setup()
    
    commit 7b31f7dadd7074fa70bb14a53bd286ffdfc98b04 upstream.
    
    For both CONFIG_NUMA enabled/disabled use mem_topology_setup() to
    update max/min_low_pfn.
    
    This also adds min_low_pfn update to CONFIG_NUMA which was initialized
    to zero before. (mpe: Though MEMORY_START is == 0 for PPC64=y which is
    all possible NUMA=y systems)
    
    Signed-off-by: Aneesh Kumar K.V <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
s390/sclp_vt220: Convert newlines to CRLF instead of LFCR [+ + +]
Author: Thomas Weißschuh <[email protected]>
Date:   Mon Oct 14 07:50:07 2024 +0200

    s390/sclp_vt220: Convert newlines to CRLF instead of LFCR
    
    commit dee3df68ab4b00fff6bdf9fc39541729af37307c upstream.
    
    According to the VT220 specification the possible character combinations
    sent on RETURN are only CR or CRLF [0].
    
            The Return key sends either a CR character (0/13) or a CR
            character (0/13) and an LF character (0/10), depending on the
            set/reset state of line feed/new line mode (LNM).
    
    The sclp/vt220 driver however uses LFCR. This can confuse tools, for
    example the kunit runner.
    
    Link: https://vt100.net/docs/vt220-rm/chapter3.html#S3.2
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: [email protected]
    Signed-off-by: Thomas Weißschuh <[email protected]>
    Reviewed-by: Sven Schnelle <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Heiko Carstens <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
tcp: fix mptcp DSS corruption due to large pmtu xmit [+ + +]
Author: Paolo Abeni <[email protected]>
Date:   Sat Oct 19 12:29:09 2024 +0200

    tcp: fix mptcp DSS corruption due to large pmtu xmit
    
    commit 4dabcdf581217e60690467a37c956a5b8dbc6bd9 upstream.
    
    Syzkaller was able to trigger a DSS corruption:
    
      TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies.
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695
      Modules linked in:
      CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
      RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695
      Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff
      RSP: 0018:ffffc90000006db8 EFLAGS: 00010246
      RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00
      RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0
      RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8
      R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000
      R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5
      FS:  000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <IRQ>
       move_skbs_to_msk net/mptcp/protocol.c:811 [inline]
       mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854
       subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490
       tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283
       tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237
       tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915
       tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350
       ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205
       ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233
       NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314
       NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314
       __netif_receive_skb_one_core net/core/dev.c:5662 [inline]
       __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775
       process_backlog+0x662/0x15b0 net/core/dev.c:6107
       __napi_poll+0xcb/0x490 net/core/dev.c:6771
       napi_poll net/core/dev.c:6840 [inline]
       net_rx_action+0x89b/0x1240 net/core/dev.c:6962
       handle_softirqs+0x2c5/0x980 kernel/softirq.c:554
       do_softirq+0x11b/0x1e0 kernel/softirq.c:455
       </IRQ>
       <TASK>
       __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382
       local_bh_enable include/linux/bottom_half.h:33 [inline]
       rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]
       __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451
       dev_queue_xmit include/linux/netdevice.h:3094 [inline]
       neigh_hh_output include/net/neighbour.h:526 [inline]
       neigh_output include/net/neighbour.h:540 [inline]
       ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236
       ip_local_out net/ipv4/ip_output.c:130 [inline]
       __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536
       __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466
       tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]
       tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline]
       tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752
       __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015
       tcp_push_pending_frames include/net/tcp.h:2107 [inline]
       tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline]
       tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239
       tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915
       sk_backlog_rcv include/net/sock.h:1113 [inline]
       __release_sock+0x214/0x350 net/core/sock.c:3072
       release_sock+0x61/0x1f0 net/core/sock.c:3626
       mptcp_push_release net/mptcp/protocol.c:1486 [inline]
       __mptcp_push_pending+0x6b5/0x9f0 net/mptcp/protocol.c:1625
       mptcp_sendmsg+0x10bb/0x1b10 net/mptcp/protocol.c:1903
       sock_sendmsg_nosec net/socket.c:730 [inline]
       __sock_sendmsg+0x1a6/0x270 net/socket.c:745
       ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2603
       ___sys_sendmsg net/socket.c:2657 [inline]
       __sys_sendmsg+0x2aa/0x390 net/socket.c:2686
       do_syscall_x64 arch/x86/entry/common.c:52 [inline]
       do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
      RIP: 0033:0x7fb06e9317f9
      Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007ffe2cfd4f98 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 00007fb06e97f468 RCX: 00007fb06e9317f9
      RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000005
      RBP: 00007fb06e97f446 R08: 0000555500000000 R09: 0000555500000000
      R10: 0000555500000000 R11: 0000000000000246 R12: 00007fb06e97f406
      R13: 0000000000000001 R14: 00007ffe2cfd4fe0 R15: 0000000000000003
       </TASK>
    
    Additionally syzkaller provided a nice reproducer. The repro enables
    pmtu on the loopback device, leading to tcp_mtu_probe() generating
    very large probe packets.
    
    tcp_can_coalesce_send_queue_head() currently does not check for
    mptcp-level invariants, and allowed the creation of cross-DSS probes,
    leading to the mentioned corruption.
    
    Address the issue teaching tcp_can_coalesce_send_queue_head() about
    mptcp using the tcp_skb_can_collapse(), also reducing the code
    duplication.
    
    Fixes: 85712484110d ("tcp: coalesce/collapse must respect MPTCP extensions")
    Cc: [email protected]
    Reported-by: [email protected]
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/513
    Signed-off-by: Paolo Abeni <[email protected]>
    Acked-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    [ Conflict in tcp_output.c, because commit 65249feb6b3d ("net: add
      support for skbs with unreadable frags"), and commit 9b65b17db723
      ("net: avoid double accounting for pure zerocopy skbs") are not in
      this version. These commits are linked to new features and introduce
      new conditions which cause the conflicts. Resolving this is easy: we
      can ignore the missing new condition, and use tcp_skb_can_collapse()
      like in the original patch. ]
    Signed-off-by: Matthieu Baerts (NGI0) <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
USB: serial: option: add support for Quectel EG916Q-GL [+ + +]
Author: Benjamin B. Frost <[email protected]>
Date:   Wed Sep 11 10:54:05 2024 +0200

    USB: serial: option: add support for Quectel EG916Q-GL
    
    commit 540eff5d7faf0c9330ec762da49df453263f7676 upstream.
    
    Add Quectel EM916Q-GL with product ID 0x6007
    
    T:  Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  3 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=2c7c ProdID=6007 Rev= 2.00
    S:  Manufacturer=Quectel
    S:  Product=EG916Q-GL
    C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=200mA
    A:  FirstIf#= 4 IfCount= 2 Cls=02(comm.) Sub=06 Prot=00
    I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 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= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=82(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=84(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E:  Ad=86(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:* If#= 4 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether
    E:  Ad=88(I) Atr=03(Int.) MxPS=  32 Ivl=32ms
    I:  If#= 5 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
    I:* If#= 5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    MI_00 Quectel USB Diag Port
    MI_01 Quectel USB NMEA Port
    MI_02 Quectel USB AT Port
    MI_03 Quectel USB Modem Port
    MI_04 Quectel USB Net Port
    
    Signed-off-by: Benjamin B. Frost <[email protected]>
    Reviewed-by: Lars Melin <[email protected]>
    Cc: [email protected]
    Signed-off-by: Johan Hovold <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

USB: serial: option: add Telit FN920C04 MBIM compositions [+ + +]
Author: Daniele Palmas <[email protected]>
Date:   Thu Oct 3 11:38:08 2024 +0200

    USB: serial: option: add Telit FN920C04 MBIM compositions
    
    commit 6d951576ee16430822a8dee1e5c54d160e1de87d upstream.
    
    Add the following Telit FN920C04 compositions:
    
    0x10a2: MBIM + tty (AT/NMEA) + tty (AT) + tty (diag)
    T:  Bus=03 Lev=01 Prnt=03 Port=06 Cnt=01 Dev#= 17 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=10a2 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN920
    S:  SerialNumber=92c4c4d8
    C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(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#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    0x10a7: MBIM + tty (AT) + tty (AT) + tty (diag)
    T:  Bus=03 Lev=01 Prnt=03 Port=06 Cnt=01 Dev#= 18 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=10a7 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN920
    S:  SerialNumber=92c4c4d8
    C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(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#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    0x10aa: MBIM + tty (AT) + tty (diag) + DPL (data packet logging) + adb
    T:  Bus=03 Lev=01 Prnt=03 Port=06 Cnt=01 Dev#= 15 Spd=480  MxCh= 0
    D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=10aa Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN920
    S:  SerialNumber=92c4c4d8
    C:  #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 4 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none)
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Signed-off-by: Daniele Palmas <[email protected]>
    Cc: [email protected]
    Signed-off-by: Johan Hovold <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
wifi: mac80211: fix potential key use-after-free [+ + +]
Author: Johannes Berg <[email protected]>
Date:   Tue Sep 19 08:34:15 2023 +0200

    wifi: mac80211: fix potential key use-after-free
    
    commit 31db78a4923ef5e2008f2eed321811ca79e7f71b upstream.
    
    When ieee80211_key_link() is called by ieee80211_gtk_rekey_add()
    but returns 0 due to KRACK protection (identical key reinstall),
    ieee80211_gtk_rekey_add() will still return a pointer into the
    key, in a potential use-after-free. This normally doesn't happen
    since it's only called by iwlwifi in case of WoWLAN rekey offload
    which has its own KRACK protection, but still better to fix, do
    that by returning an error code and converting that to success on
    the cfg80211 boundary only, leaving the error for bad callers of
    ieee80211_gtk_rekey_add().
    
    Reported-by: Dan Carpenter <[email protected]>
    Fixes: fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
    [ Sherry: bp to fix CVE-2023-52530, resolved minor conflicts in
      net/mac80211/cfg.c because of context change due to missing commit
      23a5f0af6ff4 ("wifi: mac80211: remove cipher scheme support")
      ccdde7c74ffd ("wifi: mac80211: properly implement MLO key handling")]
    Signed-off-by: Sherry Yang <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/apic: Always explicitly disarm TSC-deadline timer [+ + +]
Author: Zhang Rui <[email protected]>
Date:   Tue Oct 15 14:15:22 2024 +0800

    x86/apic: Always explicitly disarm TSC-deadline timer
    
    commit ffd95846c6ec6cf1f93da411ea10d504036cab42 upstream.
    
    New processors have become pickier about the local APIC timer state
    before entering low power modes. These low power modes are used (for
    example) when you close your laptop lid and suspend. If you put your
    laptop in a bag and it is not in this low power mode, it is likely
    to get quite toasty while it quickly sucks the battery dry.
    
    The problem boils down to some CPUs' inability to power down until the
    CPU recognizes that the local APIC timer is shut down. The current
    kernel code works in one-shot and periodic modes but does not work for
    deadline mode. Deadline mode has been the supported and preferred mode
    on Intel CPUs for over a decade and uses an MSR to drive the timer
    instead of an APIC register.
    
    Disable the TSC Deadline timer in lapic_timer_shutdown() by writing to
    MSR_IA32_TSC_DEADLINE when in TSC-deadline mode. Also avoid writing
    to the initial-count register (APIC_TMICT) which is ignored in
    TSC-deadline mode.
    
    Note: The APIC_LVTT|=APIC_LVT_MASKED operation should theoretically be
    enough to tell the hardware that the timer will not fire in any of the
    timer modes. But mitigating AMD erratum 411[1] also requires clearing
    out APIC_TMICT. Solely setting APIC_LVT_MASKED is also ineffective in
    practice on Intel Lunar Lake systems, which is the motivation for this
    change.
    
    1. 411 Processor May Exit Message-Triggered C1E State Without an Interrupt if Local APIC Timer Reaches Zero - https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/revision-guides/41322_10h_Rev_Gd.pdf
    
    Fixes: 279f1461432c ("x86: apic: Use tsc deadline for oneshot when available")
    Suggested-by: Dave Hansen <[email protected]>
    Signed-off-by: Zhang Rui <[email protected]>
    Signed-off-by: Dave Hansen <[email protected]>
    Reviewed-by: Rafael J. Wysocki <[email protected]>
    Tested-by: Srinivas Pandruvada <[email protected]>
    Tested-by: Todd Brandt <[email protected]>
    Cc: [email protected]
    Link: https://lore.kernel.org/all/20241015061522.25288-1-rui.zhang%40intel.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/bugs: Do not use UNTRAIN_RET with IBPB on entry [+ + +]
Author: Johannes Wikner <[email protected]>
Date:   Tue Oct 8 12:58:03 2024 +0200

    x86/bugs: Do not use UNTRAIN_RET with IBPB on entry
    
    commit c62fa117c32bd1abed9304c58e0da6940f8c7fc2 upstream.
    
    Since X86_FEATURE_ENTRY_IBPB will invalidate all harmful predictions
    with IBPB, no software-based untraining of returns is needed anymore.
    Currently, this change affects retbleed and SRSO mitigations so if
    either of the mitigations is doing IBPB and the other one does the
    software sequence, the latter is not needed anymore.
    
      [ bp: Massage commit message. ]
    
    Suggested-by: Borislav Petkov <[email protected]>
    Signed-off-by: Johannes Wikner <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

x86/bugs: Skip RSB fill at VMEXIT [+ + +]
Author: Johannes Wikner <[email protected]>
Date:   Tue Oct 8 12:36:30 2024 +0200

    x86/bugs: Skip RSB fill at VMEXIT
    
    commit 0fad2878642ec46225af2054564932745ac5c765 upstream.
    
    entry_ibpb() is designed to follow Intel's IBPB specification regardless
    of CPU. This includes invalidating RSB entries.
    
    Hence, if IBPB on VMEXIT has been selected, entry_ibpb() as part of the
    RET untraining in the VMEXIT path will take care of all BTB and RSB
    clearing so there's no need to explicitly fill the RSB anymore.
    
      [ bp: Massage commit message. ]
    
    Suggested-by: Borislav Petkov <[email protected]>
    Signed-off-by: Johannes Wikner <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/cpufeatures: Add a IBPB_NO_RET BUG flag [+ + +]
Author: Johannes Wikner <[email protected]>
Date:   Mon Sep 23 20:49:34 2024 +0200

    x86/cpufeatures: Add a IBPB_NO_RET BUG flag
    
    commit 3ea87dfa31a7b0bb0ff1675e67b9e54883013074 upstream.
    
    Set this flag if the CPU has an IBPB implementation that does not
    invalidate return target predictions. Zen generations < 4 do not flush
    the RSB when executing an IBPB and this bug flag denotes that.
    
      [ bp: Massage. ]
    
    Signed-off-by: Johannes Wikner <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET [+ + +]
Author: Jim Mattson <[email protected]>
Date:   Fri Sep 13 10:32:27 2024 -0700

    x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET
    
    commit ff898623af2ed564300752bba83a680a1e4fec8d upstream.
    
    AMD's initial implementation of IBPB did not clear the return address
    predictor. Beginning with Zen4, AMD's IBPB *does* clear the return address
    predictor. This behavior is enumerated by CPUID.80000008H:EBX.IBPB_RET[30].
    
    Define X86_FEATURE_AMD_IBPB_RET for use in KVM_GET_SUPPORTED_CPUID,
    when determining cross-vendor capabilities.
    
    Suggested-by: Venkatesh Srinivas <[email protected]>
    Signed-off-by: Jim Mattson <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Reviewed-by: Tom Lendacky <[email protected]>
    Reviewed-by: Thomas Gleixner <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/entry: Have entry_ibpb() invalidate return predictions [+ + +]
Author: Johannes Wikner <[email protected]>
Date:   Mon Sep 23 20:49:36 2024 +0200

    x86/entry: Have entry_ibpb() invalidate return predictions
    
    commit 50e4b3b94090babe8d4bb85c95f0d3e6b07ea86e upstream.
    
    entry_ibpb() should invalidate all indirect predictions, including return
    target predictions. Not all IBPB implementations do this, in which case the
    fallback is RSB filling.
    
    Prevent SRSO-style hijacks of return predictions following IBPB, as the return
    target predictor can be corrupted before the IBPB completes.
    
      [ bp: Massage. ]
    
    Signed-off-by: Johannes Wikner <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/entry_32: Clear CPU buffers after register restore in NMI return [+ + +]
Author: Pawan Gupta <[email protected]>
Date:   Wed Sep 25 15:25:44 2024 -0700

    x86/entry_32: Clear CPU buffers after register restore in NMI return
    
    commit 48a2440d0f20c826b884e04377ccc1e4696c84e9 upstream.
    
    CPU buffers are currently cleared after call to exc_nmi, but before
    register state is restored. This may be okay for MDS mitigation but not for
    RDFS. Because RDFS mitigation requires CPU buffers to be cleared when
    registers don't have any sensitive data.
    
    Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.
    
    Fixes: a0e2dab44d22 ("x86/entry_32: Add VERW just before userspace transition")
    Suggested-by: Dave Hansen <[email protected]>
    Signed-off-by: Pawan Gupta <[email protected]>
    Signed-off-by: Dave Hansen <[email protected]>
    Cc:[email protected]
    Link: https://lore.kernel.org/all/20240925-fix-dosemu-vm86-v7-2-1de0daca2d42%40linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

x86/entry_32: Do not clobber user EFLAGS.ZF [+ + +]
Author: Pawan Gupta <[email protected]>
Date:   Wed Sep 25 15:25:38 2024 -0700

    x86/entry_32: Do not clobber user EFLAGS.ZF
    
    commit 2e2e5143d4868163d6756c8c6a4d28cbfa5245e5 upstream.
    
    Opportunistic SYSEXIT executes VERW to clear CPU buffers after user EFLAGS
    are restored. This can clobber user EFLAGS.ZF.
    
    Move CLEAR_CPU_BUFFERS before the user EFLAGS are restored. This ensures
    that the user EFLAGS.ZF is not clobbered.
    
    Closes: https://lore.kernel.org/lkml/yVXwe8gvgmPADpRB6lXlicS2fcHoV5OHHxyuFbB_MEleRPD7-KhGe5VtORejtPe-KCkT8Uhcg5d7-IBw4Ojb4H7z5LQxoZylSmJ8KNL3A8o=@protonmail.com/
    Fixes: a0e2dab44d22 ("x86/entry_32: Add VERW just before userspace transition")
    Reported-by: Jari Ruusu <[email protected]>
    Signed-off-by: Pawan Gupta <[email protected]>
    Signed-off-by: Dave Hansen <[email protected]>
    Cc:[email protected]
    Link: https://lore.kernel.org/all/20240925-fix-dosemu-vm86-v7-1-1de0daca2d42%40linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
x86/resctrl: Annotate get_mem_config() functions as __init [+ + +]
Author: Nathan Chancellor <[email protected]>
Date:   Tue Sep 17 09:02:53 2024 -0700

    x86/resctrl: Annotate get_mem_config() functions as __init
    
    commit d5fd042bf4cfb557981d65628e1779a492cd8cfa upstream.
    
    After a recent LLVM change [1] that deduces __cold on functions that only call
    cold code (such as __init functions), there is a section mismatch warning from
    __get_mem_config_intel(), which got moved to .text.unlikely. as a result of
    that optimization:
    
      WARNING: modpost: vmlinux: section mismatch in reference: \
      __get_mem_config_intel+0x77 (section: .text.unlikely.) -> thread_throttle_mode_init (section: .init.text)
    
    Mark __get_mem_config_intel() as __init as well since it is only called
    from __init code, which clears up the warning.
    
    While __rdt_get_mem_config_amd() does not exhibit a warning because it
    does not call any __init code, it is a similar function that is only
    called from __init code like __get_mem_config_intel(), so mark it __init
    as well to keep the code symmetrical.
    
    CONFIG_SECTION_MISMATCH_WARN_ONLY=n would turn this into a fatal error.
    
    Fixes: 05b93417ce5b ("x86/intel_rdt/mba: Add primary support for Memory Bandwidth Allocation (MBA)")
    Fixes: 4d05bf71f157 ("x86/resctrl: Introduce AMD QOS feature")
    Signed-off-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Borislav Petkov (AMD) <[email protected]>
    Reviewed-by: Reinette Chatre <[email protected]>
    Cc: <[email protected]>
    Link: https://github.com/llvm/llvm-project/commit/6b11573b8c5e3d36beee099dbe7347c2a007bf53 [1]
    Link: https://lore.kernel.org/r/20240917-x86-restctrl-get_mem_config_intel-init-v3-1-10d521256284@kernel.org
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
xhci: Fix incorrect stream context type macro [+ + +]
Author: Mathias Nyman <[email protected]>
Date:   Wed Oct 16 16:59:57 2024 +0300

    xhci: Fix incorrect stream context type macro
    
    commit 6599b6a6fa8060145046d0744456b6abdb3122a7 upstream.
    
    The stream contex type (SCT) bitfield is used both in the stream context
    data structure,  and in the 'Set TR Dequeue pointer' command TRB.
    In both cases it uses bits 3:1
    
    The SCT_FOR_TRB(p) macro used to set the stream context type (SCT) field
    for the 'Set TR Dequeue pointer' command TRB incorrectly shifts the value
    1 bit left before masking the three bits.
    
    Fix this by first masking and rshifting, just like the similar
    SCT_FOR_CTX(p) macro does
    
    This issue has not been visibile as the lost bit 3 is only used with
    secondary stream arrays (SSA). Xhci driver currently only supports using
    a primary stream array with Linear stream addressing.
    
    Fixes: 95241dbdf828 ("xhci: Set SCT field for Set TR dequeue on streams")
    Cc: [email protected]
    Signed-off-by: Mathias Nyman <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>