Security Vulnerabilities - CVEs Published In 2024
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix a UBSAN warning in DML2.1
When programming phantom pipe, since cursor_width is explicity set to 0,
this causes calculation logic to trigger overflow for an unsigned int
triggering the kernel's UBSAN check as below:
[ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34
[ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int'
[ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu
[ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024
[ 40.962856] Call Trace:
[ 40.962857] <TASK>
[ 40.962860] dump_stack_lvl+0x48/0x70
[ 40.962870] dump_stack+0x10/0x20
[ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360
[ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu]
[ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu]
[ 40.963327] ? srso_alias_return_thunk+0x5/0x7f
[ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu]
[ 40.963534] ? srso_alias_return_thunk+0x5/0x7f
[ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu]
[ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu]
[ 40.963906] ? srso_alias_return_thunk+0x5/0x7f
[ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu]
[ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu]
[ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu]
[ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu]
[ 40.964587] dml21_validate+0x274/0x770 [amdgpu]
[ 40.964761] ? srso_alias_return_thunk+0x5/0x7f
[ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu]
[ 40.964942] dml2_validate+0x504/0x750 [amdgpu]
[ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu]
[ 40.965291] ? srso_alias_return_thunk+0x5/0x7f
[ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu]
[ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu]
[ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu]
[ 40.965845] ? srso_alias_return_thunk+0x5/0x7f
[ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu]
Fix this by adding a guard for checking cursor width before triggering
the size calculation.
CVSS Score
5.5
EPSS Score
0.002
Published
2024-11-08
In the Linux kernel, the following vulnerability has been resolved:
cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request()
Use raw_smp_processor_id() instead of plain smp_processor_id() in
do_service_request(), otherwise we may get some errors with the driver
enabled:
BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208
caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]
CVSS Score
5.5
EPSS Score
0.002
Published
2024-11-08
In the Linux kernel, the following vulnerability has been resolved:
ceph: remove the incorrect Fw reference check when dirtying pages
When doing the direct-io reads it will also try to mark pages dirty,
but for the read path it won't hold the Fw caps and there is case
will it get the Fw reference.
CVSS Score
5.5
EPSS Score
0.002
Published
2024-11-08
In the Linux kernel, the following vulnerability has been resolved:
fbdev: sisfb: Fix strbuf array overflow
The values of the variables xres and yres are placed in strbuf.
These variables are obtained from strbuf1.
The strbuf1 array contains digit characters
and a space if the array contains non-digit characters.
Then, when executing sprintf(strbuf, "%ux%ux8", xres, yres);
more than 16 bytes will be written to strbuf.
It is suggested to increase the size of the strbuf array to 24.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score
7.8
EPSS Score
0.003
Published
2024-11-08
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/20201124164930.GK8537@kernel.org/
[2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t
[3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/
CVSS Score
7.1
EPSS Score
0.002
Published
2024-11-08
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
EPSS Score
0.002
Published
2024-11-08
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
EPSS Score
0.002
Published
2024-11-08
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
8.2
EPSS Score
0.006
Published
2024-11-08
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
EPSS Score
0.002
Published
2024-11-08
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
7.8
EPSS Score
0.002
Published
2024-11-08