Linux: >> Linux Kernel >> 2.16.12 Security Vulnerabilities
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Additional check in ntfs_file_release
CVSS Score
7.8
EPSS Score
0.0
Published
2024-11-09
In the Linux kernel, the following vulnerability has been resolved:
udf: refactor inode_bmap() to handle error
Refactor inode_bmap() to handle error since udf_next_aext() can return
error now. On situations like ftruncate, udf_extend_file() can now
detect errors and bail out early without resorting to checking for
particular offsets and assuming internal behavior of these functions.
CVSS Score
3.3
EPSS Score
0.0
Published
2024-11-08
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
EPSS Score
0.0
Published
2024-11-08
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
EPSS Score
0.0
Published
2024-11-08
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
EPSS Score
0.0
Published
2024-11-08
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, ®);
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
EPSS Score
0.0
Published
2024-11-08
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
EPSS Score
0.0
Published
2024-11-08
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.0
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.0
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.0
Published
2024-11-08