huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2024-38629: kernel: dmaengine: idxd: Avoid unnecessary destruction of file_ida
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
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-21T00:00:00+00:00

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

dmaengine: idxd: Avoid unnecessary destruction of file_ida

file_ida is allocated during cdev open and is freed accordingly
during cdev release. This sequence is guaranteed by driver file
operations. Therefore, there is no need to destroy an already empty
file_ida when the WQ cdev is removed.

Worse, ida_free() in cdev release may happen after destruction of
file_ida per WQ cdev. This can lead to accessing an id in file_ida
after it has been destroyed, resulting in a kernel panic.

Remove ida_destroy(&file_ida) to address these issues.


Affected upstream versions: 6.4
Fixed upstream versions: 0, 6.10, 6.6.33, 6.9.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 9eb15f24a0b9b017b39cde8b8c07243676b63687
CVE-2024-38632: kernel: vfio/pci: fix potential memory leak in vfio_intx_enable()
Component: kernel
Severity: Low
CWE: CWE-402 (Transmission of Private Resources into a New Sphere ('Resource Leak'))
CVSS v3: 5.1 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:L)
Public date: 2024-06-21T00:00:00+00:00

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

vfio/pci: fix potential memory leak in vfio_intx_enable()

If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.


Affected upstream versions: 5.15.154 < 5.15.168, 6.1.84 < 6.1.113, 6.6.24 < 6.6.33, 5.4.274 < 5.5, 5.10.215 < 5.11, 6.7.12 < 6.8, 6.8.3 < 6.9, 6.9
Fixed upstream versions: 0, 5.11, 5.15.168, 5.5, 6.1.113, 6.10, 6.6.33, 6.8, 6.9, 6.9.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a6d810554d7d9d07041f14c5fcd453f3d3fed594
CVE-2024-38635: kernel: soundwire: cadence: fix invalid PDI offset
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
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-21T00:00:00+00:00

in Linux kernel soundwire, an offset is added to the PDI, which leads to an out-of-bounds error.


Affected upstream versions: <= v6.8
Fixed upstream versions: 5.10.219, 5.15.161, 5.4.278, 6.1.93, 6.10, 6.6.33, 6.9.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 002364b2d594a9afc0385c09e00994c510b1d089
CVE-2024-38663: kernel: blk-cgroup: fix list corruption from resetting io stat
Component: kernel
Severity: Low
CWE: CWE-665 (Improper Initialization)
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-24T00:00:00+00:00

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

blk-cgroup: fix list corruption from resetting io stat

Since commit 3b8cc6298724 ("blk-cgroup: Optimize blkcg_rstat_flush()"),
each iostat instance is added to blkcg percpu list, so blkcg_reset_stats()
can't reset the stat instance by memset(), otherwise the llist may be
corrupted.

Fix the issue by only resetting the counter part.


Affected upstream versions: 6.2
Fixed upstream versions: 0, 6.10, 6.6.33, 6.9.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d4a60298ac34f027a09f8f893fdbd9e06279bb24
CVE-2024-38809: org.springframework:spring-web: Spring Framework DoS via conditional HTTP request
Component: org.springframework
Severity: Moderate
CWE: CWE-1333 (Inefficient Regular Expression Complexity)
CVSS v3: 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L)
Public date: 2024-09-24T18:34:43+00:00

A flaw was found in the Spring Web (org.springframework:spring-web) package. Due to improper ETag prefix validation when the application parses ETags from the `If-Match` or `If-None-Match` request headers, an attacker can trigger a denial of service by sending a maliciously crafted conditional HTTP request.


Affected upstream versions: 6.1.0 - 6.1.11, 6.0.0 - 6.0.22, 5.3.0 - 5.3.37
Fixed upstream versions: v5.3.38
Upstream repository: https://github.com/spring-projects/spring-framework
Upstream fix commit: 582bfccbb72e5c8959a0b472d1dc7d03a20520f3
CVE-2024-39276: kernel: ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()
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-06-25T00:00:00+00:00

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

ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()

Syzbot reports a warning as follows:

============================================
WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290
Modules linked in:
CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7
RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419
Call Trace:
 <TASK>
 ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375
 generic_shutdown_super+0x136/0x2d0 fs/super.c:641
 kill_block_super+0x44/0x90 fs/super.c:1675
 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327
[...]
============================================

This is because when finding an entry in ext4_xattr_block_cache_find(), if
ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown
in the __entry_find(), won't be put away, and eventually trigger the above
issue in mb_cache_destroy() due to reference count leakage.

So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.


Affected upstream versions: 4.19.14 < 4.19.316, 4.14.92 < 4.15, 4.20.1 < 4.21, 5.0
Fixed upstream versions: 0, 4.15, 4.19.316, 4.21, 5.10.219, 5.15.161, 5.4.278, 6.1.94, 6.10, 6.6.34, 6.9.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 9ad75e78747b5a50dc5a52f0f8e92e920a653f16
CVE-2024-39331: emacs: org-link-expand-abbrev: Do not evaluate arbitrary unsafe Elisp code
Component: emacs
Severity: Moderate
CWE: CWE-95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection'))
CVSS v3: 7.8 (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)
Public date: 2024-06-23T00:00:00+00:00

A flaw was found in Emacs. Arbitrary shell commands can be executed without prompting when an Org mode file is opened or when the Org mode is enabled, when Emacs is used as an email client, this issue can be triggered when previewing email attachments.

Statement: To exploit this flaw, an attacker needs to trick a user into opening a crafted Org mode file or previewing a crafted email attachment. For this reason, this flaw has been rated with a Moderate security impact.

Affected upstream versions: n/a
Upstream repository: https://git.savannah.gnu.org/cgit/emacs/org-mode.git
Upstream fix commit: f4cc61636947b5c2f0afc67174dd369fe3277aa8
CVE-2024-39471: kernel: drm/amdgpu: add error handle to avoid out-of-bounds
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
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-25T00:00:00+00:00

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

drm/amdgpu: add error handle to avoid out-of-bounds

if the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should
be stop to avoid out-of-bounds read, so directly return -EINVAL.


Affected upstream versions: 5.4
Fixed upstream versions: 0, 5.10.219, 5.15.161, 5.4.278, 6.1.94, 6.10, 6.6.34, 6.9.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5594971e02764aa1c8210ffb838cb4e7897716e8
CVE-2024-39472: kernel: xfs: fix log recovery buffer allocation for the legacy h_size fixup
Component: kernel
Severity: Moderate
CWE: CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
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-07-05T00:00:00+00:00

A security vulnerability has been discovered in the Linux kernel's XFS file system implementation, specifically within the xlog_logrec_hblks function. This flaw arises from an inadequate log recovery buffer allocation during the processing of legacy header size adjustments. The vulnerability can be triggered by maliciously crafted inputs, leading to an out-of-bounds memory access. Successful exploitation of this condition could result in data corruption within the XFS file system.


Affected upstream versions: 5.10
Fixed upstream versions: 0, 5.15.165, 6.1.105, 6.10, 6.6.46
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f754591b17d0ee91c2b45fe9509d0cdc420527cb
CVE-2024-39473: kernel: ASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension
Component: kernel
Severity: Low
CWE: CWE-476 (NULL Pointer Dereference)
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-07-05T00:00:00+00:00

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

ASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension

If a process module does not have base config extension then the same
format applies to all of it's inputs and the process->base_config_ext is
NULL, causing NULL dereference when specifically crafted topology and
sequences used.


Affected upstream versions: 6.4
Fixed upstream versions: 0, 6.10, 6.6.34, 6.9.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e3ae00ee238bce6cfa5ad935c921181c14d18fd6
CVE-2024-39476: kernel: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING
Component: kernel
Severity: Moderate
CWE: CWE-833 (Deadlock)
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-07-05T00:00:00+00:00

A vulnerability was found in the Linux kernel's md/raid5 implementation within the raid5d() function. This flaw can cause a deadlock when handling I/O operations due to a conflict between the reconfig_mutex and the MD_SB_CHANGE_PENDING flag, leading to excessive CPU usage and denial of service.


Affected upstream versions: 4.19.262 < 4.19.316, 5.4.220 < 5.4.278, 5.10.150 < 5.10.219, 5.15.75 < 5.15.161, 4.14.296 < 4.15, 5.19.17 < 5.20, 6.0.3 < 6.1, 6.1
Fixed upstream versions: 0, 4.15, 4.19.316, 5.10.219, 5.15.161, 5.20, 5.4.278, 6.1, 6.1.94, 6.10, 6.6.34, 6.9.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b32aa95843cac6b12c2c014d40fca18aef24a347
CVE-2024-39479: kernel: drm/i915/hwmon: Get rid of devm
Component: kernel
Severity: Low
CWE: CWE-416 (Use After Free)
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-07-05T00:00:00+00:00

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

drm/i915/hwmon: Get rid of devm

When both hwmon and hwmon drvdata (on which hwmon depends) are device
managed resources, the expectation, on device unbind, is that hwmon will be
released before drvdata. However, in i915 there are two separate code
paths, which both release either drvdata or hwmon and either can be
released before the other. These code paths (for device unbind) are as
follows (see also the bug referenced below):

Call Trace:
release_nodes+0x11/0x70
devres_release_group+0xb2/0x110
component_unbind_all+0x8d/0xa0
component_del+0xa5/0x140
intel_pxp_tee_component_fini+0x29/0x40 [i915]
intel_pxp_fini+0x33/0x80 [i915]
i915_driver_remove+0x4c/0x120 [i915]
i915_pci_remove+0x19/0x30 [i915]
pci_device_remove+0x32/0xa0
device_release_driver_internal+0x19c/0x200
unbind_store+0x9c/0xb0

and

Call Trace:
release_nodes+0x11/0x70
devres_release_all+0x8a/0xc0
device_unbind_cleanup+0x9/0x70
device_release_driver_internal+0x1c1/0x200
unbind_store+0x9c/0xb0

This means that in i915, if use devm, we cannot gurantee that hwmon will
always be released before drvdata. Which means that we have a uaf if hwmon
sysfs is accessed when drvdata has been released but hwmon hasn't.

The only way out of this seems to be do get rid of devm_ and release/free
everything explicitly during device unbind.

v2: Change commit message and other minor code changes
v3: Cleanup from i915_hwmon_register on error (Armin Wolf)
v4: Eliminate potential static analyzer warning (Rodrigo)
    Eliminate fetch_and_zero (Jani)
v5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi)


Affected upstream versions: 6.2
Fixed upstream versions: 0, 6.10, 6.6.34, 6.9.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: cfa73607eb21a4ce1d6294a2c5733628897b48a2
CVE-2024-39483: kernel: KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked
Component: kernel
Severity: Low
CWE: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection'))
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-07-05T00:00:00+00:00

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

KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked

When requesting an NMI window, WARN on vNMI support being enabled if and
only if NMIs are actually masked, i.e. if the vCPU is already handling an
NMI.  KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of
view) is to inject one NMI and pend the other.  When using vNMI, KVM pends
the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the
rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected).

However, if KVM can't immediately inject an NMI, e.g. because the vCPU is
in an STI shadow or is running with GIF=0, then KVM will request an NMI
window and trigger the WARN (but still function correctly).

Whether or not the GIF=0 case makes sense is debatable, as the intent of
KVM's behavior is to provide functionality that is as close to real
hardware as possible.  E.g. if two NMIs are sent in quick succession, the
probability of both NMIs arriving in an STI shadow is infinitesimally low
on real hardware, but significantly larger in a virtual environment, e.g.
if the vCPU is preempted in the STI shadow.  For GIF=0, the argument isn't
as clear cut, because the window where two NMIs can collide is much larger
in bare metal (though still small).

That said, KVM should not have divergent behavior for the GIF=0 case based
on whether or not vNMI support is enabled.  And KVM has allowed
simultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400
("KVM: Fix simultaneous NMIs").  I.e. KVM's GIF=0 handling shouldn't be
modified without a *really* good reason to do so, and if KVM's behavior
were to be modified, it should be done irrespective of vNMI support.


Affected upstream versions: 6.4
Fixed upstream versions: 0, 6.10, 6.6.34, 6.9.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f79edaf7370986d73d204b36c50cc563a4c0f356
CVE-2024-39486: kernel: drm/drm_file: Fix pid refcounting race
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
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-07-06T00:00:00+00:00

A race condition was found in the Linux kernel. The rm_file_update_pid() only increments the refcount of a struct pid after storing a pointer to it in filp->pid, dropping the dev->filelist_mutex, resulting in a use-after-free vulnerability.


Affected upstream versions: 6.6.9 < 6.6.37, 6.7
Fixed upstream versions: 0, 6.10, 6.6.37, 6.9.8
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 16682588ead4a593cf1aebb33b36df4d1e9e4ffa
CVE-2024-39487: kernel: bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
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-07-09T00:00:00+00:00

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

bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()

In function bond_option_arp_ip_targets_set(), if newval->string is an
empty string, newval->string+1 will point to the byte after the
string, causing an out-of-bound read.

BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418
Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107
CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:364 [inline]
 print_report+0xc1/0x5e0 mm/kasan/report.c:475
 kasan_report+0xbe/0xf0 mm/kasan/report.c:588
 strlen+0x7d/0xa0 lib/string.c:418
 __fortify_strlen include/linux/fortify-string.h:210 [inline]
 in4_pton+0xa3/0x3f0 net/core/utils.c:130
 bond_option_arp_ip_targets_set+0xc2/0x910
drivers/net/bonding/bond_options.c:1201
 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767
 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792
 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817
 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156
 dev_attr_store+0x54/0x80 drivers/base/core.c:2366
 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136
 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334
 call_write_iter include/linux/fs.h:2020 [inline]
 new_sync_write fs/read_write.c:491 [inline]
 vfs_write+0x96a/0xd80 fs/read_write.c:584
 ksys_write+0x122/0x250 fs/read_write.c:637
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
---[ end trace ]---

Fix it by adding a check of string length before using it.


Affected upstream versions: 3.13
Fixed upstream versions: 0, 4.19.318, 5.10.222, 5.15.163, 5.4.280, 6.1.98, 6.10, 6.6.39, 6.9.9
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6a8a4fd082c439e19fede027e80c79bc4c84bb8e
CVE-2024-39491: kernel: ALSA: hda: cs35l56: Fix lifetime of cs_dsp instance
Component: kernel
Severity: Low
CVSS v3: 4.1 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2024-07-10T00:00:00+00:00

A flaw was found in the Linux kernel's HDA driver before initialization. This issue occurs when a user unloads and then reloads the module, and could allow a local user to crash the system.


Affected upstream versions: 6.6
Fixed upstream versions: 0, 6.10, 6.6.33, 6.9.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 9054c474f9c219e58a441e401c0e6e38fe713ff1
CVE-2024-39497: kernel: drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)
Component: kernel
Severity: Moderate
CWE: CWE-825 (Expired Pointer Dereference)
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-07-12T00:00:00+00:00

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

drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)

Lack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap
allows users to call mmap with PROT_WRITE and MAP_PRIVATE flag
causing a kernel panic due to BUG_ON in vmf_insert_pfn_prot:
BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags));

Return -EINVAL early if COW mapping is detected.

This bug affects all drm drivers using default shmem helpers.
It can be reproduced by this simple example:
void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset);
ptr[0] = 0;


Affected upstream versions: 5.2
Fixed upstream versions: 0, 5.10.229, 5.15.169, 6.1.114, 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: a508a102edf8735adc9bb73d37dd13c38d1a1b10
CVE-2024-39498: kernel: drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2
Component: kernel
Severity: Low
CWE: CWE-476 (NULL Pointer Dereference)
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-07-12T00:00:00+00:00

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

drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2

[Why]
Commit:
- commit 5aa1dfcdf0a4 ("drm/mst: Refactor the flow for payload allocation/removement")
accidently overwrite the commit
- commit 54d217406afe ("drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2")
which cause regression.

[How]
Recover the original NULL fix and remove the unnecessary input parameter 'state' for
drm_dp_add_payload_part2().

(cherry picked from commit 4545614c1d8da603e57b60dd66224d81b6ffc305)


Affected upstream versions: 6.7
Fixed upstream versions: 0, 6.10, 6.9.6
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8e21de5f99b2368a5155037ce0aae8aaba3f5241
CVE-2024-39499: kernel: vmci: prevent speculation leaks by sanitizing event in event_deliver()
Component: kernel
Severity: Moderate
CWE: CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)
CVSS v3: 4.1 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N)
Public date: 2024-07-12T00:00:00+00:00

A vulnerability was found in the event_deliver() function in the Linux kernel's VMCI component, where the issue involves a lack of sanitization for the event_data.event index controlled by user-space, which could lead to speculative information leaks.


Affected upstream versions: 3.9
Fixed upstream versions: 0, 4.19.317, 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: 58730dfbd4ae01c1b022b0d234a8bf8c02cdfb81
CVE-2024-39502: kernel: ionic: fix use after netif_napi_del()
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 6.7 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2024-07-12T00:00:00+00:00

A vulnerability was found in the Linux kernel's Ionic driver in the ionic_qcq_enable() function, where the issue arises when the driver fails to reset the .poll pointer to NULL after a queue is unregistered via netif_napi_del(), leading to a use-after-free scenario when attempting to enable a previously unregistered NAPI, which result in kernel crashes or invalid opcode errors.


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: 0d19267cb150e8f76ade210e16ee820a77f684e7