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

secretmem: disable memfd_secret() if arch cannot set direct map

Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map().  This
is the case for example on some arm64 configurations, where marking 4k
PTEs in the direct map not present can only be done if the direct map is
set up at 4k granularity in the first place (as ARM's break-before-make
semantics do not easily allow breaking apart large/gigantic pages).

More precisely, on arm64 systems with !can_set_direct_map(),
set_direct_map_invalid_noflush() is a no-op, however it returns success
(0) instead of an error.  This means that memfd_secret will seemingly
"work" (e.g.  syscall succeeds, you can mmap the fd and fault in pages),
but it does not actually achieve its goal of removing its memory from the
direct map.

Note that with this patch, memfd_secret() will start erroring on systems
where can_set_direct_map() returns false (arm64 with
CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and
CONFIG_KFENCE=n), but that still seems better than the current silent
failure.  Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most
arm64 systems actually have a working memfd_secret() and aren't be
affected.

From going through the iterations of the original memfd_secret patch
series, it seems that disabling the syscall in these scenarios was the
intended behavior [1] (preferred over having
set_direct_map_invalid_noflush return an error as that would result in
SIGBUSes at page-fault time), however the check for it got dropped between
v16 [2] and v17 [3], when secretmem moved away from CMA allocations.

[1]: https://lore.kernel.org/lkml/[PII_REDACTED]4930.GK8537@kernel.org/
[2]: https://lore.kernel.org/lkml/[PII_REDACTED]2723.3446-11-rppt@kernel.org/#t
[3]: https://lore.kernel.org/lkml/[PII_REDACTED]2208.12544-10-rppt@kernel.org/
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/532b53cebe58f34ce1c0f34d866f5c0e335c53c6; https://git.kernel.org/stable/c/5ea0b7af38754d2b45ead9257bca47e84662e926; https://git.kernel.org/stable/c/757786abe4547eb3d9d0e8350a63bdb0f9824af2
CVE: CVE-2024-50183
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance

Deleting an NPIV instance requires all fabric ndlps to be released before
an NPIV's resources can be torn down.  Failure to release fabric ndlps
beforehand opens kref imbalance race conditions.  Fix by forcing the DA_ID
to complete synchronously with usage of wait_queue.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362, CWE-362
References: https://git.kernel.org/stable/c/0857b1c573c0b095aa778bb26d8b[PII_REDACTED]b6; https://git.kernel.org/stable/c/0a3c84f71680684c1d41abb92db05f95c09111e8; https://git.kernel.org/stable/c/0ef6e016eb53fad6dc44c3253945efb43a3486b9
CVE: CVE-2024-50184
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

virtio_pmem: Check device status before requesting flush

If a pmem device is in a bad status, the driver side could wait for
host ack forever in virtio_pmem_flush(), causing the system to hang.

So add a status check in the beginning of virtio_pmem_flush() to return
early if the device is not activated.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-754, CWE-754
References: https://git.kernel.org/stable/c/4ce662fe4be6fbc2595d9ef4888b2b6e778c99ed; https://git.kernel.org/stable/c/59ac565c6277d4be6661e81ea6a7f3ca2c5e4e36; https://git.kernel.org/stable/c/6a5ca0ab94e13a1474bf7ad8437a975c2193618f
CVE: CVE-2024-50185
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

mptcp: handle consistently DSS corruption

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.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/12c1676d598e3b8dd92a033b623b792cc2ea1ec5; https://git.kernel.org/stable/c/35668f8ec84f6c944676e48ecc6bbc5fc8e6fe25; https://git.kernel.org/stable/c/8bfd391bde685df7289b928ce8876a3583be4bfb
CVE: CVE-2024-50186
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

net: explicitly clear the sk pointer, when pf->create fails

We have recently noticed the exact same KASAN splat as in commit
6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket
creation fails"). The problem is that commit did not fully address the
problem, as some pf->create implementations do not use sk_common_release
in their error paths.

For example, we can use the same reproducer as in the above commit, but
changing ping to arping. arping uses AF_PACKET socket and if packet_create
fails, it will just sk_free the allocated sk object.

While we could chase all the pf->create implementations and make sure they
NULL the freed sk object on error from the socket, we can't guarantee
future protocols will not make the same mistake.

So it is easier to just explicitly NULL the sk pointer upon return from
pf->create in __sock_create. We do know that pf->create always releases the
allocated sk object on error, so if the pointer is not NULL, it is
definitely dangling.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/563e6892e21d6ecabdf62103fc4e7b326d212334; https://git.kernel.org/stable/c/[PII_REDACTED]15d1b192bd7d915b967b37819e88ea; https://git.kernel.org/stable/c/8e1b72fd74bf9da3b099d09857f4e7f114f38e12
CVE: CVE-2024-50187
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/vc4: Stop the active perfmon before being destroyed

Upon closing the file descriptor, the active performance monitor is not
stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`,
the active performance monitor's pointer (`vc4->active_perfmon`) is still
retained.

If we open a new file descriptor and submit a few jobs with performance
monitors, the driver will attempt to stop the active performance monitor
using the stale pointer in `vc4->active_perfmon`. However, this pointer
is no longer valid because the previous process has already terminated,
and all performance monitors associated with it have been destroyed and
freed.

To fix this, when the active performance monitor belongs to a given
process, explicitly stop it before destroying and freeing it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0b2ad4f6f2bec74a5287d96cb2325a5e11706f22; https://git.kernel.org/stable/c/75452da51e2403e14be007df80d133e1443fc967; https://git.kernel.org/stable/c/937943c042503dc6087438bf3557f9057a588ba0
CVE: CVE-2024-50188
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

net: phy: dp83869: fix memory corruption when enabling fiber

When configuring the fiber port, the DP83869 PHY driver incorrectly
calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit
number (10). This corrupts some other memory location -- in case of
arm64 the priv pointer in the same structure.

Since the advertising flags are updated from supported at the end of the
function the incorrect line isn't needed at all and can be removed.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/21b5af7f0c99b3bf1fd02016e6708b613acbcaf4; https://git.kernel.org/stable/c/9ca634676ff66e1d616259e136f96f96b2a1759a; https://git.kernel.org/stable/c/a842e443ca8184f2dc82ab307b43a8b38defd6a5
CVE: CVE-2024-50189
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()

Using the device-managed version allows to simplify clean-up in probe()
error path.

Additionally, this device-managed ensures proper cleanup, which helps to
resolve memory errors, page faults, btrfs going read-only, and btrfs
disk corruption.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1c3b4c90479aa0375ec98fe1a802993ff96a5f47; https://git.kernel.org/stable/c/4cd9c5a0fcadc39a05c978a01e15e0d1edc4be93; https://git.kernel.org/stable/c/8c6ad37e5882073cab84901a31da9cb22f316276
CVE: CVE-2024-50190
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

ice: fix memleak in ice_init_tx_topology()

Fix leak of the FW blob (DDP pkg).

Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid
copying whole FW blob. Copy just the topology section, and only when
needed. Reuse the buffer allocated for the read of the current topology.

This was found by kmemleak, with the following trace for each PF:
    [<ffffffff8761044d>] kmemdup_noprof+0x1d/0x50
    [<ffffffffc0a0a480>] ice_init_ddp_config+0x100/0x220 [ice]
    [<ffffffffc0a0da7f>] ice_init_dev+0x6f/0x200 [ice]
    [<ffffffffc0a0dc49>] ice_init+0x29/0x560 [ice]
    [<ffffffffc0a10c1d>] ice_probe+0x21d/0x310 [ice]

Constify ice_cfg_tx_topo() @buf parameter.
This cascades further down to few more functions.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/43544b4e30732c3d88f[PII_REDACTED]15d5bc739b6; https://git.kernel.org/stable/c/c188afdc[PII_REDACTED]3ec78cbc036f6b05f77621
CVE: CVE-2024-50191
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: don't set SB_RDONLY after filesystem errors

When the filesystem is mounted with errors=remount-ro, we were setting
SB_RDONLY flag to stop all filesystem modifications. We knew this misses
proper locking (sb->s_umount) and does not go through proper filesystem
remount procedure but it has been the way this worked since early ext2
days and it was good enough for catastrophic situation damage
mitigation. Recently, syzbot has found a way (see link) to trigger
warnings in filesystem freezing because the code got confused by
SB_RDONLY changing under its hands. Since these days we set
EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all
filesystem modifications, modifying SB_RDONLY shouldn't be needed. So
stop doing that.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/58c0648e4c773f5b54f0cb63bc8c7c6bf52719a9; https://git.kernel.org/stable/c/d3476f3dad4ad68ae5f6b008ea6591d1520da5d8; https://git.kernel.org/stable/c/ee77c[PII_REDACTED]65e009eaa704a60bc78489e09
CVE: CVE-2024-50192
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

irqchip/gic-v4: Don't allow a VMOVP on a dying VPE

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.
CVSS Score: 4.7 (MEDIUM)
References: https://git.kernel.org/stable/c/01282ab5182f85e42234df2ff42f0ce790f465ff; https://git.kernel.org/stable/c/1442ee0011983f0c5c4b92380e6853afb513841a; https://git.kernel.org/stable/c/64b12b061c5488e2d69e67c4eaae5da64fd30bfe
CVE: CVE-2024-50193
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/entry_32: Clear CPU buffers after register restore in NMI return

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.
CVSS Score: 7.1 (HIGH)
References: https://git.kernel.org/stable/c/227358e89703c344008119be7e8ffa3fdb5b92de; https://git.kernel.org/stable/c/43778de19d2ef[PII_REDACTED]4644b9c16e78c66b; https://git.kernel.org/stable/c/48a2440d0f20c826b884e04377ccc1e4696c84e9
CVE: CVE-2024-50195
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

posix-clock: Fix missing timespec64 check in pc_clock_settime()

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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-754, CWE-754
References: https://git.kernel.org/stable/c/1ff7247101af723731ea42ed565d54fb8f341264; https://git.kernel.org/stable/c/27abbde44b6e71ee3891de13e1a228aa7ce95bfe; https://git.kernel.org/stable/c/29f085345cde24566efb751f39e5d367c381c584
CVE: CVE-2024-50196
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

pinctrl: ocelot: fix system hang on level based interrupts

The current implementation only calls chained_irq_enter() and
chained_irq_exit() if it detects pending interrupts.

```
for (i = 0; i < info->stride; i++) {
	uregmap_read(info->map, id_reg + 4 * i, &reg);
	if (!reg)
		continue;

	chained_irq_enter(parent_chip, desc);
```

However, in case of GPIO pin configured in level mode and the parent
controller configured in edge mode, GPIO interrupt might be lowered by the
hardware. In the result, if the interrupt is short enough, the parent
interrupt is still pending while the GPIO interrupt is cleared;
chained_irq_enter() never gets called and the system hangs trying to
service the parent interrupt.

Moving chained_irq_enter() and chained_irq_exit() outside the for loop
ensures that they are called even when GPIO interrupt is lowered by the
hardware.

The similar code with chained_irq_enter() / chained_irq_exit() functions
wrapping interrupt checking loop may be found in many other drivers:
```
grep -r -A 10 chained_irq_enter drivers/pinctrl
```
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-754, CWE-754
References: https://git.kernel.org/stable/c/20728e86289ab463b99b7ab4425515bd26aba417; https://git.kernel.org/stable/c/4a81800ef05bea5a9896f199677f7b7f5020776a; https://git.kernel.org/stable/c/655f5d4662b958122b260be05aa6dfdf8768efe6
CVE: CVE-2024-50197
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

pinctrl: intel: platform: fix error path in device_for_each_child_node()

The device_for_each_child_node() loop requires calls to
fwnode_handle_put() upon early returns to decrement the refcount of
the child node and avoid leaking memory if that error path is triggered.

There is one early returns within that loop in
intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is
missing.

Instead of adding the missing call, the scoped version of the loop can
be used to simplify the code and avoid mistakes in the future if new
early returns are added, as the child node is only used for parsing, and
it is never assigned.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/16a6d2e685e8f9a2f51dd5a363d3f97fcad35e22; https://git.kernel.org/stable/c/be3f7b9f995a6c2ee02767a0319929a2a98adf69
CVE: CVE-2024-50198
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: light: veml6030: fix IIO device retrieval from embedded device

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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/2cbb41abae65626736b8b52cf3b9339612c5a86a; https://git.kernel.org/stable/c/50039aec43a82ad2495f2d0fb0c289c8717b4bb2; https://git.kernel.org/stable/c/[PII_REDACTED]31beb067fffe2bdfc98031ffe89087
CVE: CVE-2024-50199
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/swapfile: skip HugeTLB pages for unuse_vma

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[PII_REDACTED]3d215d[PII_REDACTED]0000e7)

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.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/417d5838ca73c6331ae2fe692fab6c25c00d9a0b; https://git.kernel.org/stable/c/6ec0fe3756f941f42f8c57156b8bdf2877b2ebaf; https://git.kernel.org/stable/c/7528c4fb1237512ee18049f852f014eba80bbe8d
CVE: CVE-2024-50201
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/radeon: Fix encoder->possible_clones

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
...

(cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1a235af0216411a32ab4db54f7bd19020b46c86d; https://git.kernel.org/stable/c/28127dba64d8ae1a0b737b973d6d[PII_REDACTED]11; https://git.kernel.org/stable/c/68801730ebb9393460b30cd3885e407f15da27a9
CVE: CVE-2024-50202
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

nilfs2: propagate directory read errors from nilfs_find_entry()

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.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-755, CWE-755
References: https://git.kernel.org/stable/c/08cfa12adf888db98879dbd735bc741360a34168; https://git.kernel.org/stable/c/270a6f9df35fa2aea01ec23770dc9b3fc9a12989; https://git.kernel.org/stable/c/9698088ac7704e260f492d9c254e29ed7dd8729a
CVE: CVE-2024-50203
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, arm64: Fix address emission with tag-based KASAN enabled

When BPF_TRAMP_F_CALL_ORIG is enabled, the address of a bpf_tramp_image
struct on the stack is passed during the size calculation pass and
an address on the heap is passed during code generation. This may
cause a heap buffer overflow if the heap address is tagged because
emit_a64_mov_i64() will emit longer code than it did during the size
calculation pass. The same problem could occur without tag-based
KASAN if one of the 16-bit words of the stack address happened to
be all-ones during the size calculation pass. Fix the problem by
assuming the worst case (4 instructions) when calculating the size
of the bpf_tramp_image address emission.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/7db1a2121f3c7903b8e397392beec563c3d00950; https://git.kernel.org/stable/c/9e80f366ebfdfafc685fe83a84c34f7ef01cbe88; https://git.kernel.org/stable/c/a552e2ef5fd1a6c78267cd4ec5a9b49aa11bbb1c
CVE: CVE-2024-50204
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

fs: don't try and remove empty rbtree node

When copying a namespace we won't have added the new copy into the
namespace rbtree until after the copy succeeded. Calling free_mnt_ns()
will try to remove the copy from the rbtree which is invalid. Simply
free the namespace skeleton directly.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/229fd15908fe1f99b1de4cde3326e62d1e892611; https://git.kernel.org/stable/c/a8b155a2c30dc9a5ba837aa5fcba9a47cc031a9b
CVE: CVE-2024-50205
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()

The step variable is initialized to zero. It is changed in the loop,
but if it's not changed it will remain zero. Add a variable check
before the division.

The observed behavior was introduced by commit 826b5de90c0b
("ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size"),
and it is difficult to show that any of the interval parameters will
satisfy the snd_interval_test() condition with data from the
amdtp_rate_table[] table.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369, CWE-369
References: https://git.kernel.org/stable/c/3452d39c4704aa12504e4190298c721fb01083c3; https://git.kernel.org/stable/c/4bdc21506f12b2d432b1f2667e5ff4c75eee58e3; https://git.kernel.org/stable/c/5e431f85c87bbffd93a9830d5a576586f9855291
CVE: CVE-2024-50206
Published: 2024-11-08
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: mtk_eth_soc: fix memory corruption during fq dma init

The loop responsible for allocating up to MTK_FQ_DMA_LENGTH buffers must
only touch as many descriptors, otherwise it ends up corrupting unrelated
memory. Fix the loop iteration count accordingly.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787, CWE-787
References: https://git.kernel.org/stable/c/68cd084e3ec1512cd383cb3e9cf0ab7ab413724c; https://git.kernel.org/stable/c/88806efc034a9830f483963326b99930ad519af1