huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2024-36936: kernel: efi/unaccepted: touch soft lockup during memory accept
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-05-30T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

efi/unaccepted: touch soft lockup during memory accept

Commit 50e782a86c98 ("efi/unaccepted: Fix soft lockups caused by
parallel memory acceptance") has released the spinlock so other CPUs can
do memory acceptance in parallel and not triggers softlockup on other
CPUs.

However the softlock up was intermittent shown up if the memory of the
TD guest is large, and the timeout of softlockup is set to 1 second:

 RIP: 0010:_raw_spin_unlock_irqrestore
 Call Trace:
 ? __hrtimer_run_queues
 <IRQ>
 ? hrtimer_interrupt
 ? watchdog_timer_fn
 ? __sysvec_apic_timer_interrupt
 ? __pfx_watchdog_timer_fn
 ? sysvec_apic_timer_interrupt
 </IRQ>
 ? __hrtimer_run_queues
 <TASK>
 ? hrtimer_interrupt
 ? asm_sysvec_apic_timer_interrupt
 ? _raw_spin_unlock_irqrestore
 ? __sysvec_apic_timer_interrupt
 ? sysvec_apic_timer_interrupt
 accept_memory
 try_to_accept_memory
 do_huge_pmd_anonymous_page
 get_page_from_freelist
 __handle_mm_fault
 __alloc_pages
 __folio_alloc
 ? __tdx_hypercall
 handle_mm_fault
 vma_alloc_folio
 do_user_addr_fault
 do_huge_pmd_anonymous_page
 exc_page_fault
 ? __do_huge_pmd_anonymous_page
 asm_exc_page_fault
 __handle_mm_fault

When the local irq is enabled at the end of accept_memory(), the
softlockup detects that the watchdog on single CPU has not been fed for
a while. That is to say, even other CPUs will not be blocked by
spinlock, the current CPU might be stunk with local irq disabled for a
while, which hurts not only nmi watchdog but also softlockup.

Chao Gao pointed out that the memory accept could be time costly and
there was similar report before. Thus to avoid any softlocup detection
during this stage, give the softlockup a flag to skip the timeout check
at the end of accept_memory(), by invoking touch_softlockup_watchdog().


Affected upstream versions: 6.5.9 < 6.6, 6.6
Fixed upstream versions: 0, 6.6, 6.6.55, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e115c1b5de55a105c75aba8eb08301c075fa4ef4
CVE-2024-36940: kernel: pinctrl: core: delete incorrect free in pinctrl_enable()
Component: kernel
Severity: Low
CWE: CWE-415 (Double Free)
CVSS v3: 2.3 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:L)
Public date: 2024-05-30T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

pinctrl: core: delete incorrect free in pinctrl_enable()

The "pctldev" struct is allocated in devm_pinctrl_register_and_init().
It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),
so freeing it in pinctrl_enable() will lead to a double free.

The devm_pinctrl_dev_release() function frees the pindescs and destroys
the mutex as well.


Affected upstream versions: 4.11
Fixed upstream versions: 0, 4.19.314, 5.10.217, 5.15.159, 5.4.276, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 735f4c6b6771eafe336404c157ca683ad72a040d
CVE-2024-36941: kernel: wifi: nl80211: don&#39;t free NULL coalescing rule
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 5.7 (CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-05-30T00:00:00+00:00

A possible NULL pointer dereference was observed in the Linux kernel, in net/wireless/nl80211.c. This may lead to a crash.


Affected upstream versions: 3.12
Fixed upstream versions: 0, 4.19.314, 5.10.217, 5.15.159, 5.4.276, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 327382dc0f16b268950b96e0052595efd80f7b0a
CVE-2024-36944: kernel: Reapply &#34;drm/qxl: simplify qxl_fence_wait&#34;
Component: kernel
Severity: Low
CWE: CWE-833 (Deadlock)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-05-30T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

Reapply "drm/qxl: simplify qxl_fence_wait"

This reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea.

Stephen Rostedt reports:
 "I went to run my tests on my VMs and the tests hung on boot up.
  Unfortunately, the most I ever got out was:

  [   93.607888] Testing event system initcall: OK
  [   93.667730] Running tests on all trace events:
  [   93.669757] Testing all events: OK
  [   95.631064] ------------[ cut here ]------------
  Timed out after 60 seconds"

and further debugging points to a possible circular locking dependency
between the console_owner locking and the worker pool locking.

Reverting the commit allows Steve's VM to boot to completion again.

[ This may obviously result in the "[TTM] Buffer eviction failed"
  messages again, which was the reason for that original revert. But at
  this point this seems preferable to a non-booting system... ]


Affected upstream versions: 5.15.156 < 5.15.159, 6.1.87 < 6.1.91, 6.6.28 < 6.6.31, 6.8.7 < 6.8.10
Fixed upstream versions: 5.15.159, 6.1.91, 6.6.31, 6.8.10
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4a89ac4b0921c4ea21eb1b4cf3a469a91bacfcea
CVE-2024-36945: kernel: net/smc: fix neighbour and rtable leak in smc_ib_find_route()
Component: kernel
Severity: Low
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 3.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L)
Public date: 2024-05-30T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

net/smc: fix neighbour and rtable leak in smc_ib_find_route()

In smc_ib_find_route(), the neighbour found by neigh_lookup() and rtable
resolved by ip_route_output_flow() are not released or put before return.
It may cause the refcount leak, so fix it.


Affected upstream versions: 5.16
Fixed upstream versions: 0, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d5a466ab6e78d6f2e0f64435f1e17246c8e941ff
CVE-2024-36950: kernel: firewire: ohci: mask bus reset interrupts between ISR and bottom half
Component: kernel
Severity: Low
CWE: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection'))
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-05-30T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

firewire: ohci: mask bus reset interrupts between ISR and bottom half

In the FireWire OHCI interrupt handler, if a bus reset interrupt has
occurred, mask bus reset interrupts until bus_reset_work has serviced and
cleared the interrupt.

Normally, we always leave bus reset interrupts masked. We infer the bus
reset from the self-ID interrupt that happens shortly thereafter. A
scenario where we unmask bus reset interrupts was introduced in 2008 in
a007bb857e0b26f5d8b73c2ff90782d9c0972620: If
OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we
will unmask bus reset interrupts so we can log them.

irq_handler logs the bus reset interrupt. However, we can't clear the bus
reset event flag in irq_handler, because we won't service the event until
later. irq_handler exits with the event flag still set. If the
corresponding interrupt is still unmasked, the first bus reset will
usually freeze the system due to irq_handler being called again each
time it exits. This freeze can be reproduced by loading firewire_ohci
with "modprobe firewire_ohci debug=-1" (to enable all debugging output).
Apparently there are also some cases where bus_reset_work will get called
soon enough to clear the event, and operation will continue normally.

This freeze was first reported a few months after a007bb85 was committed,
but until now it was never fixed. The debug level could safely be set
to -1 through sysfs after the module was loaded, but this would be
ineffectual in logging bus reset interrupts since they were only
unmasked during initialization.

irq_handler will now leave the event flag set but mask bus reset
interrupts, so irq_handler won't be called again and there will be no
freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will
unmask the interrupt after servicing the event, so future interrupts
will be caught as desired.

As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be
enabled through sysfs in addition to during initial module loading.
However, when enabled through sysfs, logging of bus reset interrupts will
be effective only starting with the second bus reset, after
bus_reset_work has executed.


Affected upstream versions: 2.6.26
Fixed upstream versions: 0, 4.19.314, 5.10.217, 5.15.159, 5.4.276, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b3948c69d60279fce5b2eeda92a07d66296c8130
CVE-2024-36952: kernel: scsi: lpfc: Move NPIV's transport unregistration to after resource clean up
Component: kernel
Severity: Moderate
CWE: CWE-459 (Incomplete Cleanup)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-05-30T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Move NPIV's transport unregistration to after resource clean up

There are cases after NPIV deletion where the fabric switch still believes
the NPIV is logged into the fabric.  This occurs when a vport is
unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the
fabric.

Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including
the fabric D_ID, removes the last ndlp reference and frees the ndlp rport
object.  This sometimes causes the race condition where the final DA_ID and
LOGO are skipped from being sent to the fabric switch.

Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID
and LOGO are sent.


Affected upstream versions: 2.6.23
Fixed upstream versions: 0, 5.15.159, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f2c7f029051edc4b394bb48edbe2297575abefe0
CVE-2024-36953: kernel: KVM: arm64: vgic-v2: Check for non-NULL vCPU in vgic_v2_parse_attr()
Component: kernel
Severity: Low
CWE: CWE-158 (Improper Neutralization of Null Byte or NUL Character)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-05-30T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: vgic-v2: Check for non-NULL vCPU in vgic_v2_parse_attr()

vgic_v2_parse_attr() is responsible for finding the vCPU that matches
the user-provided CPUID, which (of course) may not be valid. If the ID
is invalid, kvm_get_vcpu_by_id() returns NULL, which isn't handled
gracefully.

Similar to the GICv3 uaccess flow, check that kvm_get_vcpu_by_id()
actually returns something and fail the ioctl if not.


Affected upstream versions: 4.7
Fixed upstream versions: 0, 5.10.217, 5.15.159, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4404465a1bee3607ad90a4c5f9e16dfd75b85728
CVE-2024-36954: kernel: tipc: fix a possible memleak in tipc_buf_append
Component: kernel
Severity: Low
CWE: CWE-402 (Transmission of Private Resources into a New Sphere ('Resource Leak'))
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
Public date: 2024-05-30T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

tipc: fix a possible memleak in tipc_buf_append

__skb_linearize() doesn't free the skb when it fails, so move
'*buf = NULL' after __skb_linearize(), so that the skb can be
freed on the err path.


Affected upstream versions: 4.19.193 < 4.19.314, 5.4.124 < 5.4.276, 5.10.42 < 5.10.217, 4.4.271 < 4.5, 4.9.271 < 4.10, 4.14.235 < 4.15, 5.12.9 < 5.13, 5.13
Fixed upstream versions: 0, 4.10, 4.15, 4.19.314, 4.5, 5.10.217, 5.13, 5.15.159, 5.4.276, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 01cd1b7b685751ee422d00d050292a3d277652d6
CVE-2024-36955: kernel: ALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node()
Component: kernel
Severity: Low
CWE: CWE-402 (Transmission of Private Resources into a New Sphere ('Resource Leak'))
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
Public date: 2024-05-30T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

ALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node()

The documentation for device_get_named_child_node() mentions this
important point:

"
The caller is responsible for calling fwnode_handle_put() on the
returned fwnode pointer.
"

Add fwnode_handle_put() to avoid a leaked reference.


Affected upstream versions: 5.12
Fixed upstream versions: 0, 5.15.159, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: bd2d9641a39e6b5244230c4b41c4aca83b54b377
CVE-2024-36956: kernel: thermal/debugfs: Free all thermal zone debug memory on zone removal
Component: kernel
Severity: Low
CWE: CWE-402 (Transmission of Private Resources into a New Sphere ('Resource Leak'))
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-05-30T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

thermal/debugfs: Free all thermal zone debug memory on zone removal

Because thermal_debug_tz_remove() does not free all memory allocated for
thermal zone diagnostics, some of that memory becomes unreachable after
freeing the thermal zone's struct thermal_debugfs object.

Address this by making thermal_debug_tz_remove() free all of the memory
in question.

Cc :6.8+ <stable@vger.kernel.org> # 6.8+


Affected upstream versions: 6.8
Fixed upstream versions: 0, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f51564e4b3992b53df79460ed5781a5330b5b1d5
CVE-2024-36957: kernel: octeontx2-af: avoid off-by-one read from userspace
Component: kernel
Severity: Low
CWE: CWE-193 (Off-by-one Error)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N)
Public date: 2024-05-30T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

octeontx2-af: avoid off-by-one read from userspace

We try to access count + 1 byte from userspace with memdup_user(buffer,
count + 1). However, the userspace only provides buffer of count bytes and
only these count bytes are verified to be okay to access. To ensure the
copied buffer is NUL terminated, we use memdup_user_nul instead.


Affected upstream versions: 5.10.20 < 5.10.217, 5.11.3 < 5.12, 5.12
Fixed upstream versions: 0, 5.10.217, 5.12, 5.15.159, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: bcdac70adceb44373da204c3c297f2a98e13216e
CVE-2024-36960: kernel: drm/vmwgfx: Fix invalid reads in fence signaled events
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2024-06-03T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

drm/vmwgfx: Fix invalid reads in fence signaled events

Correctly set the length of the drm_event to the size of the structure
that's actually used.

The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.


Affected upstream versions: 3.4
Fixed upstream versions: 0, 4.19.314, 5.10.217, 5.15.159, 5.4.276, 6.1.91, 6.6.31, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 2f527e3efd37c7c5e85e8aa86308856b619fa59f
CVE-2024-36961: kernel: thermal/debugfs: Fix two locking issues with thermal zone debug
Component: kernel
Severity: Low
CWE: CWE-667 (Improper Locking)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-06-03T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

thermal/debugfs: Fix two locking issues with thermal zone debug

With the current thermal zone locking arrangement in the debugfs code,
user space can open the "mitigations" file for a thermal zone before
the zone's debugfs pointer is set which will result in a NULL pointer
dereference in tze_seq_start().

Moreover, thermal_debug_tz_remove() is not called under the thermal
zone lock, so it can run in parallel with the other functions accessing
the thermal zone's struct thermal_debugfs object.  Then, it may clear
tz->debugfs after one of those functions has checked it and the
struct thermal_debugfs object may be freed prematurely.

To address the first problem, pass a pointer to the thermal zone's
struct thermal_debugfs object to debugfs_create_file() in
thermal_debug_tz_add() and make tze_seq_start(), tze_seq_next(),
tze_seq_stop(), and tze_seq_show() retrieve it from s->private
instead of a pointer to the thermal zone object.  This will ensure
that tz_debugfs will be valid across the "mitigations" file accesses
until thermal_debugfs_remove_id() called by thermal_debug_tz_remove()
removes that file.

To address the second problem, use tz->lock in thermal_debug_tz_remove()
around the tz->debugfs value check (in case the same thermal zone is
removed at the same time in two different threads) and its reset to NULL.

Cc :6.8+ <stable@vger.kernel.org> # 6.8+


Affected upstream versions: 6.8
Fixed upstream versions: 0, 6.8.10, 6.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6c57bdd0505422d5ccd2df541d993aec978c842e
CVE-2024-36967: kernel: KEYS: trusted: Fix memory leak in tpm2_key_encode()
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-06-08T00:00:00+00:00

in linux kernel, tpm2_key_encode() has a memory leak due to 'scratch' never being freed. This can lead to denial of service.


Affected upstream versions: 5.13
Fixed upstream versions: 0, 5.15.160, 6.1.92, 6.10, 6.6.32, 6.8.11, 6.9.2
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1e6914fa8e7798bcf3ce4a5b96ea4ac1d5571cdf
CVE-2024-36968: kernel: Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-06-08T00:00:00+00:00

in linux kernel bluetooth L2CAP, l2cap_le_flowctl_init() can cause both div-by-zero and an integer overflow since hdev->le_mtu may not fall in the valid range.


Affected upstream versions: 2.6.39
Fixed upstream versions: 0, 6.10, 6.6.32, 6.8.11, 6.9.2, 6.9.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ad3f7986c5a0f82b8b66a0afe1cc1f5421e1d674
CVE-2024-36971: kernel: net: kernel: UAF in network route management
Component: kernel
Severity: Important
CVSS v3: 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-06-10T00:00:00+00:00

A use-after-free flaw was found in the Linux kernel's network route management. This flaw allows an attacker to alter the behavior of certain network connections.

Statement: Environments which use third-party KABI modules may experience kernel crashes after applying errata for CVE-2024-36971. Contact your module vendor about an update. Until these third party modules can be fixed, you can prevent crashes by disabling them. This problem stems from modules which use the `negative_advice()` function.

Affected upstream versions: 4.6
Fixed upstream versions: 0, 4.19.316, 5.10.219, 5.15.161, 5.4.278, 6.1.94, 6.10, 6.6.34, 6.9.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 051c0bde9f0450a2ec3d62a86d2a0d2fad117f13
CVE-2024-36974: kernel: net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP
Component: kernel
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
CVSS v3: 6.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H)
Public date: 2024-06-18T00:00:00+00:00

in linux kernel net/sched taprio, TCA_TAPRIO_ATTR_PRIOMAP is not correctly validated if multiple calls to taprio_change() occur. This can allow arbitrary data to be injected to the kernel.


Affected upstream versions: 5.2
Fixed upstream versions: 0, 5.10.221, 5.15.162, 5.4.279, 6.1.95, 6.10, 6.6.35, 6.9.6
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c6041e7124464ce7e896ee3f912897ce88a0c4ec
CVE-2024-36977: kernel: usb: dwc3: Wait unconditionally after issuing EndXfer command
Component: kernel
Severity: Low
CWE: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection'))
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-06-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3: Wait unconditionally after issuing EndXfer command

Currently all controller IP/revisions except DWC3_usb3 >= 310a
wait 1ms unconditionally for ENDXFER completion when IOC is not
set. This is because DWC_usb3 controller revisions >= 3.10a
supports GUCTL2[14: Rst_actbitlater] bit which allows polling
CMDACT bit to know whether ENDXFER command is completed.

Consider a case where an IN request was queued, and parallelly
soft_disconnect was called (due to ffs_epfile_release). This
eventually calls stop_active_transfer with IOC cleared, hence
send_gadget_ep_cmd() skips waiting for CMDACT cleared during
EndXfer. For DWC3 controllers with revisions >= 310a, we don't
forcefully wait for 1ms either, and we proceed by unmapping the
requests. If ENDXFER didn't complete by this time, it leads to
SMMU faults since the controller would still be accessing those
requests.

Fix this by ensuring ENDXFER completion by adding 1ms delay in
__dwc3_stop_active_transfer() unconditionally.


Affected upstream versions: 6.1
Fixed upstream versions: 0, 6.1.92, 6.10, 6.6.32, 6.8.11, 6.9.2
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 341eb08dbca9eae05308c442fbfab1813a44c97a
CVE-2024-36978: kernel: net: sched: sch_multiq: fix possible OOB write in multiq_tune()
Component: kernel
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-06-19T00:00:00+00:00

An out-of-bounds write flaw was found in the Linux kernel's multiq qdisc functionality. This vulnerability allows a local user to crash or potentially escalate their privileges on the system.

Statement: This issue is for a specific configuration when the multiq of qdisc is being used. It is not easy to trigger unless the user is privileged because, apart from enabling this specific configuration, some complex conditions have to happen.

Affected upstream versions: 5.4
Fixed upstream versions: 0, 5.10.221, 5.15.162, 5.4.279, 6.1.95, 6.10, 6.6.35, 6.9.6
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d5d9d241786f49ae7cbc08e7fc95a115e9d80f3d