deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-48883
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: IPoIB, Block PKEY interfaces with less rx queues than parent

A user is able to configure an arbitrary number of rx queues when
creating an interface via netlink. This doesn't work for child PKEY
interfaces because the child interface uses the parent receive channels.

Although the child shares the parent's receive channels, the number of
rx queues is important for the channel_stats array: the parent's rx
channel index is used to access the child's channel_stats. So the array
has to be at least as large as the parent's rx queue size for the
counting to work correctly and to prevent out of bound accesses.

This patch checks for the mentioned scenario and returns an error when
trying to create the interface. The error is propagated to the user.
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/31c70bfe58ef09fe36327ddcced9143a16e9e83d; https://git.kernel.org/stable/c/5844a46f09f768da866d6b0ffbf1a9073266bf24
CVE: CVE-2022-48884
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Fix command stats access after free

Command may fail while driver is reloading and can't accept FW commands
till command interface is reinitialized. Such command failure is being
logged to command stats. This results in NULL pointer access as command
stats structure is being freed and reallocated during mlx5 devlink
reload (see kernel log below).

Fix it by making command stats statically allocated on driver probe.

Kernel log:
[ 2394.808802] BUG: unable to handle kernel paging request at[PII_REDACTED]02a9c0
[ 2394.810610] PGD 0 P4D 0
[ 2394.811811] Oops: 0002 [#1] SMP NOPTI
...
[ 2394.815482] RIP: 0010:native_queued_spin_lock_slowpath+0x183/0x1d0
...
[ 2394.829505] Call Trace:
[ 2394.830667]  _raw_spin_lock_irq+0x23/0x26
[ 2394.831858]  cmd_status_err+0x55/0x110 [mlx5_core]
[ 2394.833020]  mlx5_access_reg+0xe7/0x150 [mlx5_core]
[ 2394.834175]  mlx5_query_port_ptys+0x78/0xa0 [mlx5_core]
[ 2394.835337]  mlx5e_ethtool_get_link_ksettings+0x74/0x590 [mlx5_core]
[ 2394.836454]  ? kmem_cache_alloc_trace+0x140/0x1c0
[ 2394.837562]  __rh_call_get_link_ksettings+0x33/0x100
[ 2394.838663]  ? __rtnl_unlock+0x25/0x50
[ 2394.839755]  __ethtool_get_link_ksettings+0x72/0x150
[ 2394.840862]  duplex_show+0x6e/0xc0
[ 2394.841963]  dev_attr_show+0x1c/0x40
[ 2394.843048]  sysfs_kf_seq_show+0x9b/0x100
[ 2394.844123]  seq_read+0x153/0x410
[ 2394.845187]  vfs_read+0x91/0x140
[ 2394.846226]  ksys_read+0x4f/0xb0
[ 2394.847234]  do_syscall_64+0x5b/0x1a0
[ 2394.848228]  entry_SYSCALL_64_after_hwframe+0x65/0xca
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/da2e552b469a0cd130ff70a88ccc4139da428a65; https://git.kernel.org/stable/c/ddf458641a511e7dff19f3bf0cbbc5dd9fe08ce5
CVE: CVE-2022-48885
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ice: Fix potential memory leak in ice_gnss_tty_write()

The ice_gnss_tty_write() return directly if the write_buf alloc failed,
leaking the cmd_buf.

Fix by free cmd_buf if write_buf alloc failed.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/500ca1da9d0876244eb4d1b0ece6fa0e9968d45d; https://git.kernel.org/stable/c/f58985620f55580a07d40062c4115d8c9cf6ae27
CVE: CVE-2022-48886
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ice: Add check for kzalloc

Add the check for the return value of kzalloc in order to avoid
NULL pointer dereference.
Moreover, use the goto-label to share the clean code.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/40543b3d9d2c13227ecd3aa90a713c201d1d7f09; https://git.kernel.org/stable/c/96a[PII_REDACTED]ebb2afe76033d7329a5ecabef6e
CVE: CVE-2022-48887
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/vmwgfx: Remove rcu locks from user resources

User resource lookups used rcu to avoid two extra atomics. Unfortunately
the rcu paths were buggy and it was easy to make the driver crash by
submitting command buffers from two different threads. Because the
lookups never show up in performance profiles replace them with a
regular spin lock which fixes the races in accesses to those shared
resources.

Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and
seen crashes with apps using shared resources.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/7ac9578e45b20e3f3c0c8eb71f5417a499a7226a; https://git.kernel.org/stable/c/a309c7194e8a2f8bd4539b[PII_REDACTED]f6c2cd50
CVE: CVE-2022-48888
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/dpu: Fix memory leak in msm_mdss_parse_data_bus_icc_path

of_icc_get() alloc resources for path1, we should release it when not
need anymore. Early return when IS_ERR_OR_NULL(path0) may leak path1.
Defer getting path1 to fix this.

Patchwork: https://patchwork.freedesktop.org/patch/514264/
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/45dac1352b55b1d8cb17f218936b2bc2bc1fb4ee; https://git.kernel.org/stable/c/c6fa1de83fd87267ab24359e6fa52f98f5cee3f9
CVE: CVE-2022-48889
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: Intel: sof-nau8825: fix module alias overflow

The maximum name length for a platform_device_id entry is 20 characters
including the trailing NUL byte. The sof_nau8825.c file exceeds that,
which causes an obscure error message:

sound/soc/intel/boards/snd-soc-sof_nau8825.mod.c:35:45: error: illegal character encoding in string literal [-Werror,-Winvalid-source-encoding]
MODULE_ALIAS("platform:adl_max98373_nau8825<U+0018><AA>");
                                                   ^~~~
include/linux/module.h:168:49: note: expanded from macro 'MODULE_ALIAS'
                                                ^~~~~~
include/linux/module.h:165:56: note: expanded from macro 'MODULE_INFO'
                                                       ^~~~
include/linux/moduleparam.h:26:47: note: expanded from macro '__MODULE_INFO'
                = __MODULE_INFO_PREFIX __stringify(tag) "=" info

I could not figure out how to make the module handling robust enough
to handle this better, but as a quick fix, using slightly shorter
names that are still unique avoids the build issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-131
References: https://git.kernel.org/stable/c/3e78986a840d59dd27e636eae3f52dc11125c835; https://git.kernel.org/stable/c/fba1b23befd88366fe646787b3797e64d7338fd2
CVE: CVE-2022-48890
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: storvsc: Fix swiotlb bounce buffer leak in confidential VM

storvsc_queuecommand() maps the scatter/gather list using scsi_dma_map(),
which in a confidential VM allocates swiotlb bounce buffers. If the I/O
submission fails in storvsc_do_io(), the I/O is typically retried by higher
level code, but the bounce buffer memory is never freed.  The mostly like
cause of I/O submission failure is a full VMBus channel ring buffer, which
is not uncommon under high I/O loads.  Eventually enough bounce buffer
memory leaks that the confidential VM can't do any I/O. The same problem
can arise in a non-confidential VM with kernel boot parameter
swiotlb=force.

Fix this by doing scsi_dma_unmap() in the case of an I/O submission
error, which frees the bounce buffer memory.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/67ff3d0a49f3d445c3922e30a54e03c161da561e; https://git.kernel.org/stable/c/87c71e88f6a6619ffb1ff88f84dff48ef6d57adb
CVE: CVE-2022-48891
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

regulator: da9211: Use irq handler when ready

If the system does not come from reset (like when it is kexec()), the
regulator might have an IRQ waiting for us.

If we enable the IRQ handler before its structures are ready, we crash.

This patch fixes:

[    1.141839] Unable to handle kernel read from unreadable memory at virtual address [PII_REDACTED]
[    1.316096] Call trace:
[    1.316101]  blocking_notifier_call_chain+0x20/0xa8
[    1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests
[    1.327823]  regulator_notifier_call_chain+0x1c/0x2c
[    1.327825]  da9211_irq_handler+0x68/0xf8
[    1.327829]  irq_thread+0x11c/0x234
[    1.327833]  kthread+0x13c/0x154
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/02228f6aa6a64d588bc31e3267d05ff184d772eb; https://git.kernel.org/stable/c/1c1afcb8839b91c09d211ea304faa269763b1f91; https://git.kernel.org/stable/c/470f6a9175f13a[PII_REDACTED]8c35cc5bba33be01
CVE: CVE-2022-48892
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

sched/core: Fix use-after-free bug in dup_user_cpus_ptr()

Since commit 07ec77a1d4e8 ("sched: Allow task CPU affinity to be
restricted on asymmetric systems"), the setting and clearing of
user_cpus_ptr are done under pi_lock for arm64 architecture. However,
dup_user_cpus_ptr() accesses user_cpus_ptr without any lock
protection. Since sched_setaffinity() can be invoked from another
process, the process being modified may be undergoing fork() at
the same time.  When racing with the clearing of user_cpus_ptr in
__set_cpus_allowed_ptr_locked(), it can lead to user-after-free and
possibly double-free in arm64 kernel.

Commit 8f9ea86fdf99 ("sched: Always preserve the user requested
cpumask") fixes this problem as user_cpus_ptr, once set, will never
be cleared in a task's lifetime. However, this bug was re-introduced
in commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in
do_set_cpus_allowed()") which allows the clearing of user_cpus_ptr in
do_set_cpus_allowed(). This time, it will affect all arches.

Fix this bug by always clearing the user_cpus_ptr of the newly
cloned/forked task before the copying process starts and check the
user_cpus_ptr state of the source task under pi_lock.

Note to stable, this patch won't be applicable to stable releases.
Just copy the new dup_user_cpus_ptr() function over.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415, CWE-416
References: https://git.kernel.org/stable/c/7b5cc7fd1789ea5dbb942c9f8207b076d365badc; https://git.kernel.org/stable/c/87ca4f9efbd7cc649ff43b87970888f2812945b8; https://git.kernel.org/stable/c/b22faa21b6230d5eccd233e1b7e0026a5002b287
CVE: CVE-2022-48893
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/i915/gt: Cleanup partial engine discovery failures

If we abort driver initialisation in the middle of gt/engine discovery,
some engines will be fully setup and some not. Those incompletely setup
engines only have 'engine->release == NULL' and so will leak any of the
common objects allocated.

v2:
 - Drop the destroy_pinned_context() helper for now.  It's not really
   worth it with just a single callsite at the moment.  (Janusz)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-459
References: https://git.kernel.org/stable/c/5c855bcc730656c4b7d30aaddcd0eafc7003e112; https://git.kernel.org/stable/c/78350c36fb15afef423404a83dcbc5c558dce795; https://git.kernel.org/stable/c/78a033433a5ae4fee85511ee075bc9a48312c79e
CVE: CVE-2022-48894
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/arm-smmu-v3: Don't unregister on shutdown

Similar to SMMUv2, this driver calls iommu_device_unregister() from the
shutdown path, which removes the IOMMU groups with no coordination
whatsoever with their users - shutdown methods are optional in device
drivers. This can lead to NULL pointer dereferences in those drivers'
DMA API calls, or worse.

Instead of calling the full arm_smmu_device_remove() from
arm_smmu_device_shutdown(), let's pick only the relevant function call -
arm_smmu_device_disable() - more or less the reverse of
arm_smmu_device_reset() - and call just that from the shutdown path.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/32ea2c57dc216b6ad8125fa680d31daa5d421c95; https://git.kernel.org/stable/c/ead3e6c[PII_REDACTED]4c777fd329afc125fecde48
CVE: CVE-2022-48896
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ixgbe: fix pci device refcount leak

As the comment of pci_get_domain_bus_and_slot() says, it
returns a PCI device with refcount incremented, when finish
using it, the caller must decrement the reference count by
calling pci_dev_put().

In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(),
pci_dev_put() is called to avoid leak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/112df4cd2b09acd64bcd18f5ef83ba5d07b34bf0; https://git.kernel.org/stable/c/4c93422a54cd6a349988f42e1c6bf082cf4ea9d8; https://git.kernel.org/stable/c/53cefa802f070d46c0c518f4865be2c749818a18
CVE: CVE-2022-48897
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64/mm: fix incorrect file_map_count for invalid pmd

The page table check trigger BUG_ON() unexpectedly when split hugepage:

 ------------[ cut here ]------------
 kernel BUG at mm/page_table_check.c:119!
 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
 Dumping ftrace buffer:
    (ftrace buffer empty)
 Modules linked in:
 CPU: 7 PID: 210 Comm: transhuge-stres Not tainted 6.1.0-rc3+ #748
 Hardware name: linux,dummy-virt (DT)
 pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : page_table_check_set.isra.0+0x398/0x468
 lr : page_table_check_set.isra.0+0x1c0/0x468
[...]
 Call trace:
  page_table_check_set.isra.0+0x398/0x468
  __page_table_check_pte_set+0x160/0x1c0
  __split_huge_pmd_locked+0x900/0x1648
  __split_huge_pmd+0x28c/0x3b8
  unmap_page_range+0x428/0x858
  unmap_single_vma+0xf4/0x1c8
  zap_page_range+0x2b0/0x410
  madvise_vma_behavior+0xc44/0xe78
  do_madvise+0x280/0x698
  __arm64_sys_madvise+0x90/0xe8
  invoke_syscall.constprop.0+0xdc/0x1d8
  do_el0_svc+0xf4/0x3f8
  el0_svc+0x58/0x120
  el0t_64_sync_handler+0xb8/0xc0
  el0t_64_sync+0x19c/0x1a0
[...]

On arm64, pmd_leaf() will return true even if the pmd is invalid due to
pmd_present_invalid() check. So in pmdp_invalidate() the file_map_count
will not only decrease once but also increase once. Then in set_pte_at(),
the file_map_count increase again, and so trigger BUG_ON() unexpectedly.

Add !pmd_present_invalid() check in pmd_user_accessible_page() to fix the
problem.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/21e5eca0ac9046da9918a919bc92b7b5a78d27e7; https://git.kernel.org/stable/c/74c2f81054510d45b813548cb0a1c4ebf87cdd5f
CVE: CVE-2022-48898
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer

There are 3 possible interrupt sources are handled by DP controller,
HPDstatus, Controller state changes and Aux read/write transaction.
At every irq, DP controller have to check isr status of every interrupt
sources and service the interrupt if its isr status bits shows interrupts
are pending. There is potential race condition may happen at current aux
isr handler implementation since it is always complete dp_aux_cmd_fifo_tx()
even irq is not for aux read or write transaction. This may cause aux read
transaction return premature if host aux data read is in the middle of
waiting for sink to complete transferring data to host while irq happen.
This will cause host's receiving buffer contains unexpected data. This
patch fixes this problem by checking aux isr and return immediately at
aux isr handler if there are no any isr status bits set.

Current there is a bug report regrading eDP edid corruption happen during
system booting up. After lengthy debugging to found that VIDEO_READY
interrupt was continuously firing during system booting up which cause
dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data
from aux hardware buffer which is not yet contains complete data transfer
from sink. This cause edid corruption.

Follows are the signature at kernel logs when problem happen,
EDID has corrupt header
panel-simple-dp-aux aux-aea0000.edp: Couldn't identify panel via EDID

Changes in v2:
-- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr()
-- add more commit text

Changes in v3:
-- add Stephen suggested
-- dp_aux_isr() return IRQ_XXX back to caller
-- dp_ctrl_isr() return IRQ_XXX back to caller

Changes in v4:
-- split into two patches

Changes in v5:
-- delete empty line between tags

Changes in v6:
-- remove extra "that" and fixed line more than 75 char at commit text

Patchwork: https://patchwork.freedesktop.org/patch/516121/
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/1cba0d150fa102439114a91b3e215909efc9f169; https://git.kernel.org/stable/c/785607e5e6fb52caf141e4580de40405565f04f1; https://git.kernel.org/stable/c/984ad875db804948c86ca9e1c2e784ae8252715a
CVE: CVE-2022-48899
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/virtio: Fix GEM handle creation UAF

Userspace can guess the handle value and try to race GEM object creation
with handle close, resulting in a use-after-free if we dereference the
object after dropping the handle's reference.  For that reason, dropping
the handle's reference must be done *after* we are done dereferencing
the object.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/011ecdbcd520c90c344b872ca6b4821f7783b2f8; https://git.kernel.org/stable/c/19ec87d06acfab2313ee82b2a689bf0c154e57ea; https://git.kernel.org/stable/c/[PII_REDACTED]8ed59a2dc5a43df2eaf0eb1d65438e
CVE: CVE-2023-52893
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

gsmi: fix null-deref in gsmi_get_variable

We can get EFI variables without fetching the attribute, so we must
allow for that in gsmi.

commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore
access layer") added a new get_variable call with attr=NULL, which
triggers panic in gsmi.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/32313c11bdc8a02c577abaf865be3664ab30410a; https://git.kernel.org/stable/c/6646d769fdb0ce4318ef9afd127f8526d1ca8393; https://git.kernel.org/stable/c/a769b05eeed7accc4019a1ed9799dd72067f1ce8
CVE: CVE-2023-52894
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()

In Google internal bug 265639009 we've received an (as yet) unreproducible
crash report from an aarch64 GKI 5.10.149-android13 running device.

AFAICT the source code is at:
  https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10

The call stack is:
  ncm_close() -> ncm_notify() -> ncm_do_notify()
with the crash at:
  ncm_do_notify+0x98/0x270
Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)

Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...):

  // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification)
  0B 0D 00 79    strh w11, [x8, #6]

  // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request)
  6C 0A 00 B9    str  w12, [x19, #8]

  // x10 (NULL) was read here from offset 0 of valid pointer x9
  // IMHO we're reading 'cdev->gadget' and getting NULL
  // gadget is indeed at offset 0 of struct usb_composite_dev
  2A 01 40 F9    ldr  x10, [x9]

  // loading req->buf pointer, which is at offset 0 of struct usb_request
  69 02 40 F9    ldr  x9, [x19]

  // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed
  4B 5D 40 B9    ldr  w11, [x10, #0x5c]

which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:

  event->wLength = cpu_to_le16(8);
  req->length = NCM_STATUS_BYTECOUNT;

  /* SPEED_CHANGE data is up/down speeds in bits/sec */
  data = req->buf + sizeof *event;
  data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));

My analysis of registers and NULL ptr deref crash offset
  (Unable to handle kernel NULL pointer dereference at virtual address[PII_REDACTED]00005c)
heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing:
  data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));
which calls:
  ncm_bitrate(NULL)
which then calls:
  gadget_is_superspeed(NULL)
which reads
  ((struct usb_gadget *)NULL)->max_speed
and hits a panic.

AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.
(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)

It's not at all clear to me how this is all supposed to work...
but returning 0 seems much better than panic-ing...
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/09e4507ec8ef2d44da6ba4092b8ee2d81f216497; https://git.kernel.org/stable/c/63d161f29cd39c050e8873aa36e0c9fc013bb763; https://git.kernel.org/stable/c/a21da7f7aae618c785f7e4a275d43c06dc8412b6
CVE: CVE-2023-52895
Published: 2024-08-21
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring/poll: don't reissue in case of poll race on multishot request

A previous commit fixed a poll race that can occur, but it's only
applicable for multishot requests. For a multishot request, we can safely
ignore a spurious wakeup, as we never leave the waitqueue to begin with.

A blunt reissue of a multishot armed request can cause us to leak a
buffer, if they are ring provided. While this seems like a bug in itself,
it's not really defined behavior to reissue a multishot request directly.
It's less efficient to do so as well, and not required to rearm anything
like it is for singleshot poll requests.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/36fc7317cdb16cfeae0f[PII_REDACTED]37bb615ac4; https://git.kernel.org/stable/c/8caa03f10bf92cb8657408a6ece6a8a73f96ce13