Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/gic-v4: Don&amp;#39;t allow a VMOVP on a dying VPE<br /> <br /> Kunkun Jiang reported that there is a small window of opportunity for<br /> userspace to force a change of affinity for a VPE while the VPE has already<br /> been unmapped, but the corresponding doorbell interrupt still visible in<br /> /proc/irq/.<br /> <br /> Plug the race by checking the value of vmapp_count, which tracks whether<br /> the VPE is mapped ot not, and returning an error in this case.<br /> <br /> This involves making vmapp_count common to both GICv4.1 and its v4.0<br /> ancestor.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/entry_32: Clear CPU buffers after register restore in NMI return<br /> <br /> CPU buffers are currently cleared after call to exc_nmi, but before<br /> register state is restored. This may be okay for MDS mitigation but not for<br /> RDFS. Because RDFS mitigation requires CPU buffers to be cleared when<br /> registers don&amp;#39;t have any sensitive data.<br /> <br /> Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: probes: Fix uprobes for big-endian kernels<br /> <br /> The arm64 uprobes code is broken for big-endian kernels as it doesn&amp;#39;t<br /> convert the in-memory instruction encoding (which is always<br /> little-endian) into the kernel&amp;#39;s native endianness before analyzing and<br /> simulating instructions. This may result in a few distinct problems:<br /> <br /> * The kernel may may erroneously reject probing an instruction which can<br /> safely be probed.<br /> <br /> * The kernel may erroneously erroneously permit stepping an<br /> instruction out-of-line when that instruction cannot be stepped<br /> out-of-line safely.<br /> <br /> * The kernel may erroneously simulate instruction incorrectly dur to<br /> interpretting the byte-swapped encoding.<br /> <br /> The endianness mismatch isn&amp;#39;t caught by the compiler or sparse because:<br /> <br /> * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so<br /> the compiler and sparse have no idea these contain a little-endian<br /> 32-bit value. The core uprobes code populates these with a memcpy()<br /> which similarly does not handle endianness.<br /> <br /> * While the uprobe_opcode_t type is an alias for __le32, both<br /> arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]<br /> to the similarly-named probe_opcode_t, which is an alias for u32.<br /> Hence there is no endianness conversion warning.<br /> <br /> Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and<br /> adding the appropriate __le32_to_cpu() conversions prior to consuming<br /> the instruction encoding. The core uprobes copies these fields as opaque<br /> ranges of bytes, and so is unaffected by this change.<br /> <br /> At the same time, remove MAX_UINSN_BYTES and consistently use<br /> AARCH64_INSN_SIZE for clarity.<br /> <br /> Tested with the following:<br /> <br /> | #include <br /> | #include <br /> |<br /> | #define noinline __attribute__((noinline))<br /> |<br /> | static noinline void *adrp_self(void)<br /> | {<br /> | void *addr;<br /> |<br /> | asm volatile(<br /> | " adrp %x0, adrp_self\n"<br /> | " add %x0, %x0, :lo12:adrp_self\n"<br /> | : "=r" (addr));<br /> | }<br /> |<br /> |<br /> | int main(int argc, char *argv)<br /> | {<br /> | void *ptr = adrp_self();<br /> | bool equal = (ptr == adrp_self);<br /> |<br /> | printf("adrp_self =&gt; %p\n"<br /> | "adrp_self() =&gt; %p\n"<br /> | "%s\n",<br /> | adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL");<br /> |<br /> | return 0;<br /> | }<br /> <br /> .... where the adrp_self() function was compiled to:<br /> <br /> | 00000000004007e0 :<br /> | 4007e0: 90000000 adrp x0, 400000 <br /> | 4007e4: 911f8000 add x0, x0, #0x7e0<br /> | 4007e8: d65f03c0 ret<br /> <br /> Before this patch, the ADRP is not recognized, and is assumed to be<br /> steppable, resulting in corruption of the result:<br /> <br /> | # ./adrp-self<br /> | adrp_self =&gt; 0x4007e0<br /> | adrp_self() =&gt; 0x4007e0<br /> | EQUAL<br /> | # echo &amp;#39;p /root/adrp-self:0x007e0&amp;#39; &gt; /sys/kernel/tracing/uprobe_events<br /> | # echo 1 &gt; /sys/kernel/tracing/events/uprobes/enable<br /> | # ./adrp-self<br /> | adrp_self =&gt; 0x4007e0<br /> | adrp_self() =&gt; 0xffffffffff7e0<br /> | NOT EQUAL<br /> <br /> After this patch, the ADRP is correctly recognized and simulated:<br /> <br /> | # ./adrp-self<br /> | adrp_self =&gt; 0x4007e0<br /> | adrp_self() =&gt; 0x4007e0<br /> | EQUAL<br /> | #<br /> | # echo &amp;#39;p /root/adrp-self:0x007e0&amp;#39; &gt; /sys/kernel/tracing/uprobe_events<br /> | # echo 1 &gt; /sys/kernel/tracing/events/uprobes/enable<br /> | # ./adrp-self<br /> | adrp_self =&gt; 0x4007e0<br /> | adrp_self() =&gt; 0x4007e0<br /> | EQUAL

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 /> ext4: don&amp;#39;t set SB_RDONLY after filesystem errors<br /> <br /> When the filesystem is mounted with errors=remount-ro, we were setting<br /> SB_RDONLY flag to stop all filesystem modifications. We knew this misses<br /> proper locking (sb-&gt;s_umount) and does not go through proper filesystem<br /> remount procedure but it has been the way this worked since early ext2<br /> days and it was good enough for catastrophic situation damage<br /> mitigation. Recently, syzbot has found a way (see link) to trigger<br /> warnings in filesystem freezing because the code got confused by<br /> SB_RDONLY changing under its hands. Since these days we set<br /> EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all<br /> filesystem modifications, modifying SB_RDONLY shouldn&amp;#39;t be needed. So<br /> stop doing that.