Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> posix-clock: Fix missing timespec64 check in pc_clock_settime()<br /> <br /> As Andrew pointed out, it will make sense that the PTP core<br /> checked timespec64 struct&amp;#39;s tv_sec and tv_nsec range before calling<br /> ptp-&gt;info-&gt;settime64().<br /> <br /> As the man manual of clock_settime() said, if tp.tv_sec is negative or<br /> tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,<br /> which include dynamic clocks which handles PTP clock, and the condition is<br /> consistent with timespec64_valid(). As Thomas suggested, timespec64_valid()<br /> only check the timespec is valid, but not ensure that the time is<br /> in a valid range, so check it ahead using timespec64_valid_strict()<br /> in pc_clock_settime() and return -EINVAL if not valid.<br /> <br /> There are some drivers that use tp-&gt;tv_sec and tp-&gt;tv_nsec directly to<br /> write registers without validity checks and assume that the higher layer<br /> has checked it, which is dangerous and will benefit from this, such as<br /> hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),<br /> and some drivers can remove the checks of itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: ocelot: fix system hang on level based interrupts<br /> <br /> The current implementation only calls chained_irq_enter() and<br /> chained_irq_exit() if it detects pending interrupts.<br /> <br /> ```<br /> for (i = 0; i stride; i++) {<br /> uregmap_read(info-&gt;map, id_reg + 4 * i, &amp;reg);<br /> if (!reg)<br /> continue;<br /> <br /> chained_irq_enter(parent_chip, desc);<br /> ```<br /> <br /> However, in case of GPIO pin configured in level mode and the parent<br /> controller configured in edge mode, GPIO interrupt might be lowered by the<br /> hardware. In the result, if the interrupt is short enough, the parent<br /> interrupt is still pending while the GPIO interrupt is cleared;<br /> chained_irq_enter() never gets called and the system hangs trying to<br /> service the parent interrupt.<br /> <br /> Moving chained_irq_enter() and chained_irq_exit() outside the for loop<br /> ensures that they are called even when GPIO interrupt is lowered by the<br /> hardware.<br /> <br /> The similar code with chained_irq_enter() / chained_irq_exit() functions<br /> wrapping interrupt checking loop may be found in many other drivers:<br /> ```<br /> grep -r -A 10 chained_irq_enter drivers/pinctrl<br /> ```

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: light: veml6030: fix IIO device retrieval from embedded device<br /> <br /> The dev pointer that is received as an argument in the<br /> in_illuminance_period_available_show function references the device<br /> embedded in the IIO device, not in the i2c client.<br /> <br /> dev_to_iio_dev() must be used to accessthe right data. The current<br /> implementation leads to a segmentation fault on every attempt to read<br /> the attribute because indio_dev gets a NULL assignment.<br /> <br /> This bug has been present since the first appearance of the driver,<br /> apparently since the last version (V6) before getting applied. A<br /> constant attribute was used until then, and the last modifications might<br /> have not been tested again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/swapfile: skip HugeTLB pages for unuse_vma<br /> <br /> I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The<br /> problem can be reproduced by the following steps:<br /> <br /> 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory.<br /> 2. Swapout the above anonymous memory.<br /> 3. run swapoff and we will get a bad pud error in kernel message:<br /> <br /> mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7)<br /> <br /> We can tell that pud_clear_bad is called by pud_none_or_clear_bad in<br /> unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never<br /> be freed because we lost it from page table. We can skip HugeTLB pages<br /> for unuse_vma to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> maple_tree: correct tree corruption on spanning store<br /> <br /> Patch series "maple_tree: correct tree corruption on spanning store", v3.<br /> <br /> There has been a nasty yet subtle maple tree corruption bug that appears<br /> to have been in existence since the inception of the algorithm.<br /> <br /> This bug seems far more likely to happen since commit f8d112a4e657<br /> ("mm/mmap: avoid zeroing vma tree in mmap_region()"), which is the point<br /> at which reports started to be submitted concerning this bug.<br /> <br /> We were made definitely aware of the bug thanks to the kind efforts of<br /> Bert Karwatzki who helped enormously in my being able to track this down<br /> and identify the cause of it.<br /> <br /> The bug arises when an attempt is made to perform a spanning store across<br /> two leaf nodes, where the right leaf node is the rightmost child of the<br /> shared parent, AND the store completely consumes the right-mode node.<br /> <br /> This results in mas_wr_spanning_store() mitakenly duplicating the new and<br /> existing entries at the maximum pivot within the range, and thus maple<br /> tree corruption.<br /> <br /> The fix patch corrects this by detecting this scenario and disallowing the<br /> mistaken duplicate copy.<br /> <br /> The fix patch commit message goes into great detail as to how this occurs.<br /> <br /> This series also includes a test which reliably reproduces the issue, and<br /> asserts that the fix works correctly.<br /> <br /> Bert has kindly tested the fix and confirmed it resolved his issues. Also<br /> Mikhail Gavrilov kindly reported what appears to be precisely the same<br /> bug, which this fix should also resolve.<br /> <br /> <br /> This patch (of 2):<br /> <br /> There has been a subtle bug present in the maple tree implementation from<br /> its inception.<br /> <br /> This arises from how stores are performed - when a store occurs, it will<br /> overwrite overlapping ranges and adjust the tree as necessary to<br /> accommodate this.<br /> <br /> A range may always ultimately span two leaf nodes. In this instance we<br /> walk the two leaf nodes, determine which elements are not overwritten to<br /> the left and to the right of the start and end of the ranges respectively<br /> and then rebalance the tree to contain these entries and the newly<br /> inserted one.<br /> <br /> This kind of store is dubbed a &amp;#39;spanning store&amp;#39; and is implemented by<br /> mas_wr_spanning_store().<br /> <br /> In order to reach this stage, mas_store_gfp() invokes<br /> mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to<br /> walk the tree and update the object (mas) to traverse to the location<br /> where the write should be performed, determining its store type.<br /> <br /> When a spanning store is required, this function returns false stopping at<br /> the parent node which contains the target range, and mas_wr_store_type()<br /> marks the mas-&gt;store_type as wr_spanning_store to denote this fact.<br /> <br /> When we go to perform the store in mas_wr_spanning_store(), we first<br /> determine the elements AFTER the END of the range we wish to store (that<br /> is, to the right of the entry to be inserted) - we do this by walking to<br /> the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we<br /> have just determined contains the range over which we intend to write.<br /> <br /> We then turn our attention to the entries to the left of the entry we are<br /> inserting, whose state is represented by l_mas, and copy these into a &amp;#39;big<br /> node&amp;#39;, which is a special node which contains enough slots to contain two<br /> leaf node&amp;#39;s worth of data.<br /> <br /> We then copy the entry we wish to store immediately after this - the copy<br /> and the insertion of the new entry is performed by mas_store_b_node().<br /> <br /> After this we copy the elements to the right of the end of the range which<br /> we are inserting, if we have not exceeded the length of the node (i.e. <br /> r_mas.offset

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/radeon: Fix encoder-&gt;possible_clones<br /> <br /> Include the encoder itself in its possible_clones bitmask.<br /> In the past nothing validated that drivers were populating<br /> possible_clones correctly, but that changed in commit<br /> 74d2aacbe840 ("drm: Validate encoder-&gt;possible_clones").<br /> Looks like radeon never got the memo and is still not<br /> following the rules 100% correctly.<br /> <br /> This results in some warnings during driver initialization:<br /> Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7)<br /> WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c<br /> ...<br /> <br /> (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: propagate directory read errors from nilfs_find_entry()<br /> <br /> Syzbot reported that a task hang occurs in vcs_open() during a fuzzing<br /> test for nilfs2.<br /> <br /> The root cause of this problem is that in nilfs_find_entry(), which<br /> searches for directory entries, ignores errors when loading a directory<br /> page/folio via nilfs_get_folio() fails.<br /> <br /> If the filesystem images is corrupted, and the i_size of the directory<br /> inode is large, and the directory page/folio is successfully read but<br /> fails the sanity check, for example when it is zero-filled,<br /> nilfs_check_folio() may continue to spit out error messages in bursts.<br /> <br /> Fix this issue by propagating the error to the callers when loading a<br /> page/folio fails in nilfs_find_entry().<br /> <br /> The current interface of nilfs_find_entry() and its callers is outdated<br /> and cannot propagate error codes such as -EIO and -ENOMEM returned via<br /> nilfs_find_entry(), so fix it together.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()<br /> <br /> The step variable is initialized to zero. It is changed in the loop,<br /> but if it&amp;#39;s not changed it will remain zero. Add a variable check<br /> before the division.<br /> <br /> The observed behavior was introduced by commit 826b5de90c0b<br /> ("ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size"),<br /> and it is difficult to show that any of the interval parameters will<br /> satisfy the snd_interval_test() condition with data from the<br /> amdtp_rate_table[] table.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: fix a UBSAN warning in DML2.1<br /> <br /> When programming phantom pipe, since cursor_width is explicity set to 0,<br /> this causes calculation logic to trigger overflow for an unsigned int<br /> triggering the kernel&amp;#39;s UBSAN check as below:<br /> <br /> [ 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<br /> [ 40.962849] shift exponent 4294967170 is too large for 32-bit type &amp;#39;unsigned int&amp;#39;<br /> [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu<br /> [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024<br /> [ 40.962856] Call Trace:<br /> [ 40.962857] <br /> [ 40.962860] dump_stack_lvl+0x48/0x70<br /> [ 40.962870] dump_stack+0x10/0x20<br /> [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360<br /> [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu]<br /> [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu]<br /> [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f<br /> [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu]<br /> [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f<br /> [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu]<br /> [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu]<br /> [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f<br /> [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu]<br /> [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu]<br /> [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu]<br /> [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu]<br /> [ 40.964587] dml21_validate+0x274/0x770 [amdgpu]<br /> [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f<br /> [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu]<br /> [ 40.964942] dml2_validate+0x504/0x750 [amdgpu]<br /> [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu]<br /> [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f<br /> [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu]<br /> [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu]<br /> [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu]<br /> [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f<br /> [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu]<br /> <br /> Fix this by adding a guard for checking cursor width before triggering<br /> the size calculation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request()<br /> <br /> Use raw_smp_processor_id() instead of plain smp_processor_id() in<br /> do_service_request(), otherwise we may get some errors with the driver<br /> enabled:<br /> <br /> BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208<br /> caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix memleak in ice_init_tx_topology()<br /> <br /> Fix leak of the FW blob (DDP pkg).<br /> <br /> Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid<br /> copying whole FW blob. Copy just the topology section, and only when<br /> needed. Reuse the buffer allocated for the read of the current topology.<br /> <br /> This was found by kmemleak, with the following trace for each PF:<br /> [] kmemdup_noprof+0x1d/0x50<br /> [] ice_init_ddp_config+0x100/0x220 [ice]<br /> [] ice_init_dev+0x6f/0x200 [ice]<br /> [] ice_init+0x29/0x560 [ice]<br /> [] ice_probe+0x21d/0x310 [ice]<br /> <br /> Constify ice_cfg_tx_topo() @buf parameter.<br /> This cascades further down to few more functions.