Vulnerabilities

Multiple vulnerabilities in the web-based management interface of Cisco Small Business SPA300 Series IP Phones and Cisco Small Business SPA500 Series IP Phones could allow an unauthenticated, remote attacker to execute arbitrary commands on the underlying operating system with root privileges.<br /> <br /> These vulnerabilities exist because incoming HTTP packets are not properly checked for errors, which could result in a buffer overflow. An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected device. A successful exploit could allow the attacker to overflow an internal buffer and execute arbitrary commands at the root privilege level.

A vulnerability in the web-based management interface of Cisco ISE could allow an authenticated, remote attacker to conduct an XSS attack against a user of the interface.<br /> <br /> This vulnerability is due to insufficient validation of user-supplied input by the web-based management interface of an affected system. An attacker could exploit this vulnerability by injecting malicious code into specific pages of the interface. A successful exploit could allow the attacker to execute arbitrary script code in the context of the affected interface or access sensitive, browser-based information. To exploit this vulnerability, the attacker must have Admin privileges on an affected device.

A vulnerability, which was classified as critical, has been found in Tenda i22 1.0.0.3(4687). This issue affects the function formApPortalOneKeyAuth of the file /goform/apPortalOneKeyAuth. The manipulation of the argument data leads to buffer overflow. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: sdhci: Fix max_seg_size for 64KiB PAGE_SIZE<br /> <br /> blk_queue_max_segment_size() ensured:<br /> <br /> if (max_size max_segment_size

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray<br /> <br /> Patch series "mm/filemap: Limit page cache size to that supported by<br /> xarray", v2.<br /> <br /> Currently, xarray can&amp;#39;t support arbitrary page cache size. More details<br /> can be found from the WARN_ON() statement in xas_split_alloc(). In our<br /> test whose code is attached below, we hit the WARN_ON() on ARM64 system<br /> where the base page size is 64KB and huge page size is 512MB. The issue<br /> was reported long time ago and some discussions on it can be found here<br /> [1].<br /> <br /> [1] https://www.spinics.net/lists/linux-xfs/msg75404.html<br /> <br /> In order to fix the issue, we need to adjust MAX_PAGECACHE_ORDER to one<br /> supported by xarray and avoid PMD-sized page cache if needed. The code<br /> changes are suggested by David Hildenbrand.<br /> <br /> PATCH[1] adjusts MAX_PAGECACHE_ORDER to that supported by xarray<br /> PATCH[2-3] avoids PMD-sized page cache in the synchronous readahead path<br /> PATCH[4] avoids PMD-sized page cache for shmem files if needed<br /> <br /> Test program<br /> ============<br /> # cat test.c<br /> #define _GNU_SOURCE<br /> #include <br /> #include <br /> #include <br /> #include <br /> #include <br /> #include <br /> #include <br /> #include <br /> <br /> #define TEST_XFS_FILENAME "/tmp/data"<br /> #define TEST_SHMEM_FILENAME "/dev/shm/data"<br /> #define TEST_MEM_SIZE 0x20000000<br /> <br /> int main(int argc, char **argv)<br /> {<br /> const char *filename;<br /> int fd = 0;<br /> void *buf = (void *)-1, *p;<br /> int pgsize = getpagesize();<br /> int ret;<br /> <br /> if (pgsize != 0x10000) {<br /> fprintf(stderr, "64KB base page size is required\n");<br /> return -EPERM;<br /> }<br /> <br /> system("echo force &gt; /sys/kernel/mm/transparent_hugepage/shmem_enabled");<br /> system("rm -fr /tmp/data");<br /> system("rm -fr /dev/shm/data");<br /> system("echo 1 &gt; /proc/sys/vm/drop_caches");<br /> <br /> /* Open xfs or shmem file */<br /> filename = TEST_XFS_FILENAME;<br /> if (argc &gt; 1 &amp;&amp; !strcmp(argv[1], "shmem"))<br /> filename = TEST_SHMEM_FILENAME;<br /> <br /> fd = open(filename, O_CREAT | O_RDWR | O_TRUNC);<br /> if (fd 0)<br /> close(fd);<br /> <br /> return 0;<br /> }<br /> <br /> # gcc test.c -o test<br /> # cat /proc/1/smaps | grep KernelPageSize | head -n 1<br /> KernelPageSize: 64 kB<br /> # ./test shmem<br /> :<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 17 PID: 5253 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128<br /> Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \<br /> nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \<br /> nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \<br /> ip_set nf_tables rfkill nfnetlink vfat fat virtio_balloon \<br /> drm fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 \<br /> virtio_net sha1_ce net_failover failover virtio_console virtio_blk \<br /> dimlib virtio_mmio<br /> CPU: 17 PID: 5253 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #12<br /> Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024<br /> pstate: 83400005 (Nzcv daif +PAN -UAO +TC<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: serial: mos7840: fix crash on resume<br /> <br /> Since commit c49cfa917025 ("USB: serial: use generic method if no<br /> alternative is provided in usb serial layer"), USB serial core calls the<br /> generic resume implementation when the driver has not provided one.<br /> <br /> This can trigger a crash on resume with mos7840 since support for<br /> multiple read URBs was added back in 2011. Specifically, both port read<br /> URBs are now submitted on resume for open ports, but the context pointer<br /> of the second URB is left set to the core rather than mos7840 port<br /> structure.<br /> <br /> Fix this by implementing dedicated suspend and resume functions for<br /> mos7840.<br /> <br /> Tested with Delock 87414 USB 2.0 to 4x serial adapter.<br /> <br /> [ johan: analyse crash and rewrite commit message; set busy flag on<br /> resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "sched/fair: Make sure to try to detach at least one movable task"<br /> <br /> This reverts commit b0defa7ae03ecf91b8bfd10ede430cff12fcbd06.<br /> <br /> b0defa7ae03ec changed the load balancing logic to ignore env.max_loop if<br /> all tasks examined to that point were pinned. The goal of the patch was<br /> to make it more likely to be able to detach a task buried in a long list<br /> of pinned tasks. However, this has the unfortunate side effect of<br /> creating an O(n) iteration in detach_tasks(), as we now must fully<br /> iterate every task on a cpu if all or most are pinned. Since this load<br /> balance code is done with rq lock held, and often in softirq context, it<br /> is very easy to trigger hard lockups. We observed such hard lockups with<br /> a user who affined O(10k) threads to a single cpu.<br /> <br /> When I discussed this with Vincent he initially suggested that we keep<br /> the limit on the number of tasks to detach, but increase the number of<br /> tasks we can search. However, after some back and forth on the mailing<br /> list, he recommended we instead revert the original patch, as it seems<br /> likely no one was actually getting hit by the original issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket<br /> <br /> When using a BPF program on kernel_connect(), the call can return -EPERM. This<br /> causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing<br /> the kernel to potentially freeze up.<br /> <br /> Neil suggested:<br /> <br /> This will propagate -EPERM up into other layers which might not be ready<br /> to handle it. It might be safer to map EPERM to an error we would be more<br /> likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.<br /> <br /> ECONNREFUSED as error seems reasonable. For programs setting a different error<br /> can be out of reach (see handling in 4fbac77d2d09) in particular on kernels<br /> which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err<br /> instead of allow boolean"), thus given that it is better to simply remap for<br /> consistent behavior. UDP does handle EPERM in xs_udp_send_request().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wireguard: allowedips: avoid unaligned 64-bit memory accesses<br /> <br /> On the parisc platform, the kernel issues kernel warnings because<br /> swap_endian() tries to load a 128-bit IPv6 address from an unaligned<br /> memory location:<br /> <br /> Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df)<br /> Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)<br /> <br /> Avoid such unaligned memory accesses by instead using the<br /> get_unaligned_be64() helper macro.<br /> <br /> [Jason: replace src[8] in original patch with src+8]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: ma35d1: Add a NULL check for of_node<br /> <br /> The pdev-&gt;dev.of_node can be NULL if the "serial" node is absent.<br /> Add a NULL check to return an error in such cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: don&amp;#39;t unoptimize message in spi_async()<br /> <br /> Calling spi_maybe_unoptimize_message() in spi_async() is wrong because<br /> the message is likely to be in the queue and not transferred yet. This<br /> can corrupt the message while it is being used by the controller driver.<br /> <br /> spi_maybe_unoptimize_message() is already called in the correct place<br /> in spi_finalize_current_message() to balance the call to<br /> spi_maybe_optimize_message() in spi_async().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: add missing lock protection when polling<br /> <br /> Add missing lock protection in poll routine when iterating xarray,<br /> otherwise:<br /> <br /> Even with RCU read lock held, only the slot of the radix tree is<br /> ensured to be pinned there, while the data structure (e.g. struct<br /> cachefiles_req) stored in the slot has no such guarantee. The poll<br /> routine will iterate the radix tree and dereference cachefiles_req<br /> accordingly. Thus RCU read lock is not adequate in this case and<br /> spinlock is needed here.