Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning<br /> <br /> Fix a smatch static checker warning on vdec_vp8_req_if.c.<br /> Which leads to a kernel crash when fb is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning<br /> <br /> Fix a smatch static checker warning on vdec_h264_req_multi_if.c.<br /> Which leads to a kernel crash when fb is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos<br /> <br /> In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL<br /> referencing a non-existing BTF type, function bpf_core_calc_relo_insn<br /> would cause a null pointer deference.<br /> <br /> Fix this by adding a proper check upper in call stack, as malformed<br /> relocation records could be passed from user space.<br /> <br /> Simplest reproducer is a program:<br /> <br /> r0 = 0<br /> exit<br /> <br /> With a single relocation record:<br /> <br /> .insn_off = 0, /* patch first instruction */<br /> .type_id = 100500, /* this type id does not exist */<br /> .access_str_off = 6, /* offset of string "0" */<br /> .kind = BPF_CORE_TYPE_ID_LOCAL,<br /> <br /> See the link for original reproducer or next commit for a test case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm: Clean up TPM space after command failure<br /> <br /> tpm_dev_transmit prepares the TPM space before attempting command<br /> transmission. However if the command fails no rollback of this<br /> preparation is done. This can result in transient handles being leaked<br /> if the device is subsequently closed with no further commands performed.<br /> <br /> Fix this by flushing the space in the event of command transmission<br /> failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()<br /> <br /> The kref_put() function will call nport-&gt;release if the refcount drops to<br /> zero. The nport-&gt;release release function is _efc_nport_free() which frees<br /> "nport". But then we dereference "nport" on the next line which is a use<br /> after free. Re-order these lines to avoid the use after free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08<br /> <br /> Currently rsv_qp is freed before ib_unregister_device() is called<br /> on HIP08. During the time interval, users can still dereg MR and<br /> rsv_qp will be used in this process, leading to a UAF. Move the<br /> release of rsv_qp after calling ib_unregister_device() to fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port()<br /> <br /> Within kirin_pcie_parse_port(), the pcie-&gt;num_slots is compared to<br /> pcie-&gt;gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead<br /> to an overflow.<br /> <br /> Thus, fix condition to pcie-&gt;num_slots + 1 &gt;= MAX_PCI_SLOTS and move<br /> pcie-&gt;num_slots increment below the if-statement to avoid out-of-bounds<br /> array access.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.<br /> <br /> [kwilczynski: commit log]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: keystone: Fix if-statement expression in ks_pcie_quirk()<br /> <br /> This code accidentally uses &amp;&amp; where || was intended. It potentially<br /> results in a NULL dereference.<br /> <br /> Thus, fix the if-statement expression to use the correct condition.<br /> <br /> [kwilczynski: commit log]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix potential oob read in nilfs_btree_check_delete()<br /> <br /> The function nilfs_btree_check_delete(), which checks whether degeneration<br /> to direct mapping occurs before deleting a b-tree entry, causes memory<br /> access outside the block buffer when retrieving the maximum key if the<br /> root node has no entries.<br /> <br /> This does not usually happen because b-tree mappings with 0 child nodes<br /> are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen<br /> if the b-tree root node read from a device is configured that way, so fix<br /> this potential issue by adding a check for that case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix race setting file private on concurrent lseek using same fd<br /> <br /> When doing concurrent lseek(2) system calls against the same file<br /> descriptor, using multiple threads belonging to the same process, we have<br /> a short time window where a race happens and can result in a memory leak.<br /> <br /> The race happens like this:<br /> <br /> 1) A program opens a file descriptor for a file and then spawns two<br /> threads (with the pthreads library for example), lets call them<br /> task A and task B;<br /> <br /> 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at<br /> file.c:find_desired_extent() while holding a read lock on the inode;<br /> <br /> 3) At the start of find_desired_extent(), it extracts the file&amp;#39;s<br /> private_data pointer into a local variable named &amp;#39;private&amp;#39;, which has<br /> a value of NULL;<br /> <br /> 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode<br /> in shared mode and enters file.c:find_desired_extent(), where it also<br /> extracts file-&gt;private_data into its local variable &amp;#39;private&amp;#39;, which<br /> has a NULL value;<br /> <br /> 5) Because it saw a NULL file private, task A allocates a private<br /> structure and assigns to the file structure;<br /> <br /> 6) Task B also saw a NULL file private so it also allocates its own file<br /> private and then assigns it to the same file structure, since both<br /> tasks are using the same file descriptor.<br /> <br /> At this point we leak the private structure allocated by task A.<br /> <br /> Besides the memory leak, there&amp;#39;s also the detail that both tasks end up<br /> using the same cached state record in the private structure (struct<br /> btrfs_file_private::llseek_cached_state), which can result in a<br /> use-after-free problem since one task can free it while the other is<br /> still using it (only one task took a reference count on it). Also, sharing<br /> the cached state is not a good idea since it could result in incorrect<br /> results in the future - right now it should not be a problem because it<br /> end ups being used only in extent-io-tree.c:count_range_bits() where we do<br /> range validation before using the cached state.<br /> <br /> Fix this by protecting the private assignment and check of a file while<br /> holding the inode&amp;#39;s spinlock and keep track of the task that allocated<br /> the private, so that it&amp;#39;s used only by that task in order to prevent<br /> user-after-free issues with the cached state record as well as potentially<br /> using it incorrectly in the future.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock<br /> <br /> Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock<br /> on x86 due to a chain of locks and SRCU synchronizations. Translating the<br /> below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on<br /> CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there&amp;#39;s a writer, due to the<br /> fairness of r/w semaphores).<br /> <br /> CPU0 CPU1 CPU2<br /> 1 lock(&amp;kvm-&gt;slots_lock);<br /> 2 lock(&amp;vcpu-&gt;mutex);<br /> 3 lock(&amp;kvm-&gt;srcu);<br /> 4 lock(cpu_hotplug_lock);<br /> 5 lock(kvm_lock);<br /> 6 lock(&amp;kvm-&gt;slots_lock);<br /> 7 lock(cpu_hotplug_lock);<br /> 8 sync(&amp;kvm-&gt;srcu);<br /> <br /> Note, there are likely more potential deadlocks in KVM x86, e.g. the same<br /> pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with<br /> __kvmclock_cpufreq_notifier():<br /> <br /> cpuhp_cpufreq_online()<br /> |<br /> -&gt; cpufreq_online()<br /> |<br /> -&gt; cpufreq_gov_performance_limits()<br /> |<br /> -&gt; __cpufreq_driver_target()<br /> |<br /> -&gt; __target_index()<br /> |<br /> -&gt; cpufreq_freq_transition_begin()<br /> |<br /> -&gt; cpufreq_notify_transition()<br /> |<br /> -&gt; ... __kvmclock_cpufreq_notifier()<br /> <br /> But, actually triggering such deadlocks is beyond rare due to the<br /> combination of dependencies and timings involved. E.g. the cpufreq<br /> notifier is only used on older CPUs without a constant TSC, mucking with<br /> the NX hugepage mitigation while VMs are running is very uncommon, and<br /> doing so while also onlining/offlining a CPU (necessary to generate<br /> contention on cpu_hotplug_lock) would be even more unusual.<br /> <br /> The most robust solution to the general cpu_hotplug_lock issue is likely<br /> to switch vm_list to be an RCU-protected list, e.g. so that x86&amp;#39;s cpufreq<br /> notifier doesn&amp;#39;t to take kvm_lock. For now, settle for fixing the most<br /> blatant deadlock, as switching to an RCU-protected list is a much more<br /> involved change, but add a comment in locking.rst to call out that care<br /> needs to be taken when walking holding kvm_lock and walking vm_list.<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O<br /> ------------------------------------------------------<br /> tee/35048 is trying to acquire lock:<br /> ff6a80eced71e0a8 (&amp;kvm-&gt;slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm]<br /> <br /> but task is already holding lock:<br /> ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm]<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #3 (kvm_lock){+.+.}-{3:3}:<br /> __mutex_lock+0x6a/0xb40<br /> mutex_lock_nested+0x1f/0x30<br /> kvm_dev_ioctl+0x4fb/0xe50 [kvm]<br /> __se_sys_ioctl+0x7b/0xd0<br /> __x64_sys_ioctl+0x21/0x30<br /> x64_sys_call+0x15d0/0x2e60<br /> do_syscall_64+0x83/0x160<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> -&gt; #2 (cpu_hotplug_lock){++++}-{0:0}:<br /> cpus_read_lock+0x2e/0xb0<br /> static_key_slow_inc+0x16/0x30<br /> kvm_lapic_set_base+0x6a/0x1c0 [kvm]<br /> kvm_set_apic_base+0x8f/0xe0 [kvm]<br /> kvm_set_msr_common+0x9ae/0xf80 [kvm]<br /> vmx_set_msr+0xa54/0xbe0 [kvm_intel]<br /> __kvm_set_msr+0xb6/0x1a0 [kvm]<br /> kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm]<br /> kvm_vcpu_ioctl+0x485/0x5b0 [kvm]<br /> __se_sys_ioctl+0x7b/0xd0<br /> __x64_sys_ioctl+0x21/0x30<br /> x64_sys_call+0x15d0/0x2e60<br /> do_syscall_64+0x83/0x160<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> -&gt; #1 (&amp;kvm-&gt;srcu){.+.+}-{0:0}:<br /> __synchronize_srcu+0x44/0x1a0<br /> <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set<br /> <br /> This may be a typo. The comment has said shared locks are<br /> not allowed when this bit is set. If using shared lock, the<br /> wait in `fuse_file_cached_io_open` may be forever.