Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/hwmon: Get rid of devm<br /> <br /> When both hwmon and hwmon drvdata (on which hwmon depends) are device<br /> managed resources, the expectation, on device unbind, is that hwmon will be<br /> released before drvdata. However, in i915 there are two separate code<br /> paths, which both release either drvdata or hwmon and either can be<br /> released before the other. These code paths (for device unbind) are as<br /> follows (see also the bug referenced below):<br /> <br /> Call Trace:<br /> release_nodes+0x11/0x70<br /> devres_release_group+0xb2/0x110<br /> component_unbind_all+0x8d/0xa0<br /> component_del+0xa5/0x140<br /> intel_pxp_tee_component_fini+0x29/0x40 [i915]<br /> intel_pxp_fini+0x33/0x80 [i915]<br /> i915_driver_remove+0x4c/0x120 [i915]<br /> i915_pci_remove+0x19/0x30 [i915]<br /> pci_device_remove+0x32/0xa0<br /> device_release_driver_internal+0x19c/0x200<br /> unbind_store+0x9c/0xb0<br /> <br /> and<br /> <br /> Call Trace:<br /> release_nodes+0x11/0x70<br /> devres_release_all+0x8a/0xc0<br /> device_unbind_cleanup+0x9/0x70<br /> device_release_driver_internal+0x1c1/0x200<br /> unbind_store+0x9c/0xb0<br /> <br /> This means that in i915, if use devm, we cannot gurantee that hwmon will<br /> always be released before drvdata. Which means that we have a uaf if hwmon<br /> sysfs is accessed when drvdata has been released but hwmon hasn&amp;#39;t.<br /> <br /> The only way out of this seems to be do get rid of devm_ and release/free<br /> everything explicitly during device unbind.<br /> <br /> v2: Change commit message and other minor code changes<br /> v3: Cleanup from i915_hwmon_register on error (Armin Wolf)<br /> v4: Eliminate potential static analyzer warning (Rodrigo)<br /> Eliminate fetch_and_zero (Jani)<br /> v5: Restore previous logic for ddat_gt-&gt;hwmon_dev error return (Andi)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kdb: Fix buffer overflow during tab-complete<br /> <br /> Currently, when the user attempts symbol completion with the Tab key, kdb<br /> will use strncpy() to insert the completed symbol into the command buffer.<br /> Unfortunately it passes the size of the source buffer rather than the<br /> destination to strncpy() with predictably horrible results. Most obviously<br /> if the command buffer is already full but cp, the cursor position, is in<br /> the middle of the buffer, then we will write past the end of the supplied<br /> buffer.<br /> <br /> Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()<br /> calls plus explicit boundary checks to make sure we have enough space<br /> before we start moving characters around.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mc: Fix graph walk in media_pipeline_start<br /> <br /> The graph walk tries to follow all links, even if they are not between<br /> pads. This causes a crash with, e.g. a MEDIA_LNK_FL_ANCILLARY_LINK link.<br /> <br /> Fix this by allowing the walk to proceed only for MEDIA_LNK_FL_DATA_LINK<br /> links.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked<br /> <br /> When requesting an NMI window, WARN on vNMI support being enabled if and<br /> only if NMIs are actually masked, i.e. if the vCPU is already handling an<br /> NMI. KVM&amp;#39;s ABI for NMIs that arrive simultanesouly (from KVM&amp;#39;s point of<br /> view) is to inject one NMI and pend the other. When using vNMI, KVM pends<br /> the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the<br /> rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected).<br /> <br /> However, if KVM can&amp;#39;t immediately inject an NMI, e.g. because the vCPU is<br /> in an STI shadow or is running with GIF=0, then KVM will request an NMI<br /> window and trigger the WARN (but still function correctly).<br /> <br /> Whether or not the GIF=0 case makes sense is debatable, as the intent of<br /> KVM&amp;#39;s behavior is to provide functionality that is as close to real<br /> hardware as possible. E.g. if two NMIs are sent in quick succession, the<br /> probability of both NMIs arriving in an STI shadow is infinitesimally low<br /> on real hardware, but significantly larger in a virtual environment, e.g.<br /> if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn&amp;#39;t<br /> as clear cut, because the window where two NMIs can collide is much larger<br /> in bare metal (though still small).<br /> <br /> That said, KVM should not have divergent behavior for the GIF=0 case based<br /> on whether or not vNMI support is enabled. And KVM has allowed<br /> simultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400<br /> ("KVM: Fix simultaneous NMIs"). I.e. KVM&amp;#39;s GIF=0 handling shouldn&amp;#39;t be<br /> modified without a *really* good reason to do so, and if KVM&amp;#39;s behavior<br /> were to be modified, it should be done irrespective of vNMI support.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l: async: Properly re-initialise notifier entry in unregister<br /> <br /> The notifier_entry of a notifier is not re-initialised after unregistering<br /> the notifier. This leads to dangling pointers being left there so use<br /> list_del_init() to return the notifier_entry an empty list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcache: fix variable length array abuse in btree_iter<br /> <br /> btree_iter is used in two ways: either allocated on the stack with a<br /> fixed size MAX_BSETS, or from a mempool with a dynamic size based on the<br /> specific cache set. Previously, the struct had a fixed-length array of<br /> size MAX_BSETS which was indexed out-of-bounds for the dynamically-sized<br /> iterators, which causes UBSAN to complain.<br /> <br /> This patch uses the same approach as in bcachefs&amp;#39;s sort_iter and splits<br /> the iterator into a btree_iter with a flexible array member and a<br /> btree_iter_stack which embeds a btree_iter as well as a fixed-length<br /> data array.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix log recovery buffer allocation for the legacy h_size fixup<br /> <br /> Commit a70f9fe52daa ("xfs: detect and handle invalid iclog size set by<br /> mkfs") added a fixup for incorrect h_size values used for the initial<br /> umount record in old xfsprogs versions. Later commit 0c771b99d6c9<br /> ("xfs: clean up calculation of LR header blocks") cleaned up the log<br /> reover buffer calculation, but stoped using the fixed up h_size value<br /> to size the log recovery buffer, which can lead to an out of bounds<br /> access when the incorrect h_size does not come from the old mkfs<br /> tool, but a fuzzer.<br /> <br /> Fix this by open coding xlog_logrec_hblks and taking the fixed h_size<br /> into account for this calculation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL<br /> <br /> commit a421ef303008 ("mm: allow !GFP_KERNEL allocations for kvmalloc")<br /> includes support for __GFP_NOFAIL, but it presents a conflict with commit<br /> dd544141b9eb ("vmalloc: back off when the current task is OOM-killed"). A<br /> possible scenario is as follows:<br /> <br /> process-a<br /> __vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL)<br /> __vmalloc_area_node()<br /> vm_area_alloc_pages()<br /> --&gt; oom-killer send SIGKILL to process-a<br /> if (fatal_signal_pending(current)) break;<br /> --&gt; return NULL;<br /> <br /> To fix this, do not check fatal_signal_pending() in vm_area_alloc_pages()<br /> if __GFP_NOFAIL set.<br /> <br /> This issue occurred during OPLUS KASAN TEST. Below is part of the log<br /> -&gt; oom-killer sends signal to process<br /> [65731.222840] [ T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/uid_10198,task=gs.intelligence,pid=32454,uid=10198<br /> <br /> [65731.259685] [T32454] Call trace:<br /> [65731.259698] [T32454] dump_backtrace+0xf4/0x118<br /> [65731.259734] [T32454] show_stack+0x18/0x24<br /> [65731.259756] [T32454] dump_stack_lvl+0x60/0x7c<br /> [65731.259781] [T32454] dump_stack+0x18/0x38<br /> [65731.259800] [T32454] mrdump_common_die+0x250/0x39c [mrdump]<br /> [65731.259936] [T32454] ipanic_die+0x20/0x34 [mrdump]<br /> [65731.260019] [T32454] atomic_notifier_call_chain+0xb4/0xfc<br /> [65731.260047] [T32454] notify_die+0x114/0x198<br /> [65731.260073] [T32454] die+0xf4/0x5b4<br /> [65731.260098] [T32454] die_kernel_fault+0x80/0x98<br /> [65731.260124] [T32454] __do_kernel_fault+0x160/0x2a8<br /> [65731.260146] [T32454] do_bad_area+0x68/0x148<br /> [65731.260174] [T32454] do_mem_abort+0x151c/0x1b34<br /> [65731.260204] [T32454] el1_abort+0x3c/0x5c<br /> [65731.260227] [T32454] el1h_64_sync_handler+0x54/0x90<br /> [65731.260248] [T32454] el1h_64_sync+0x68/0x6c<br /> <br /> [65731.260269] [T32454] z_erofs_decompress_queue+0x7f0/0x2258<br /> --&gt; be-&gt;decompressed_pages = kvcalloc(be-&gt;nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL);<br /> kernel panic by NULL pointer dereference.<br /> erofs assume kvmalloc with __GFP_NOFAIL never return NULL.<br /> [65731.260293] [T32454] z_erofs_runqueue+0xf30/0x104c<br /> [65731.260314] [T32454] z_erofs_readahead+0x4f0/0x968<br /> [65731.260339] [T32454] read_pages+0x170/0xadc<br /> [65731.260364] [T32454] page_cache_ra_unbounded+0x874/0xf30<br /> [65731.260388] [T32454] page_cache_ra_order+0x24c/0x714<br /> [65731.260411] [T32454] filemap_fault+0xbf0/0x1a74<br /> [65731.260437] [T32454] __do_fault+0xd0/0x33c<br /> [65731.260462] [T32454] handle_mm_fault+0xf74/0x3fe0<br /> [65731.260486] [T32454] do_mem_abort+0x54c/0x1b34<br /> [65731.260509] [T32454] el0_da+0x44/0x94<br /> [65731.260531] [T32454] el0t_64_sync_handler+0x98/0xb4<br /> [65731.260553] [T32454] el0t_64_sync+0x198/0x19c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: davinci: Don&amp;#39;t strip remove function when driver is builtin<br /> <br /> Using __exit for the remove function results in the remove callback being<br /> discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.<br /> using sysfs or hotplug), the driver is just removed without the cleanup<br /> being performed. This results in resource leaks. Fix it by compiling in the<br /> remove callback unconditionally.<br /> <br /> This also fixes a W=1 modpost warning:<br /> <br /> WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in<br /> reference: davinci_mmcsd_driver+0x10 (section: .data) -&gt;<br /> davinci_mmcsd_remove (section: .exit.text)

KSmserver in KDE Plasma Workspace (aka plasma-workspace) before 5.27.11.1 and 6.x before 6.0.5.1 allows connections via ICE based purely on the host, i.e., all local connections are accepted. This allows another user on the same machine to gain access to the session manager, e.g., use the session-restore feature to execute arbitrary code as the victim (on the next boot) via earlier use of the /tmp directory.

The IPv6 implementation in the Linux kernel before 6.3 has a net/ipv6/route.c max_size threshold that can be consumed easily, e.g., leading to a denial of service (network is unreachable errors) when IPv6 packets are sent in a loop via a raw socket.

drupal-wiki.com Drupal Wiki before 8.31.1 allows XSS via comments, captions, and image titles of a Wiki page.