Vulnerabilities

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.

An issue was discovered in OpenStack Cinder through 24.0.0, Glance before 28.0.2, and Nova before 29.0.3. Arbitrary file access can occur via custom QCOW2 external data. By supplying a crafted QCOW2 image that references a specific data file path, an authenticated user may convince systems to return a copy of that file&amp;#39;s contents from the server, resulting in unauthorized access to potentially sensitive data. All Cinder and Nova deployments are affected; only Glance deployments with image conversion enabled are affected.

rejetto HFS (aka HTTP File Server) 3 before 0.52.10 on Linux, UNIX, and macOS allows OS command execution by remote authenticated users (if they have Upload permissions). This occurs because a shell is used to execute df (i.e., with execSync instead of spawnSync in child_process in Node.js).

supOS 5.0 allows api/image/download?fileName=../ directory traversal for reading files.

jc21 NGINX Proxy Manager before 2.11.3 allows backend/internal/certificate.js OS command injection by an authenticated user (with certificate management privileges) via untrusted input to the DNS provider configuration. NOTE: this is not part of any NGINX software shipped by F5.