Vulnerabilities

Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in WPDeveloper Typing Text allows Stored XSS.This issue affects Typing Text: from n/a through 1.2.5.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-buf/sw-sync: don&amp;#39;t enable IRQ from sync_print_obj()<br /> <br /> Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from<br /> known context") by error replaced spin_unlock_irqrestore() with<br /> spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite<br /> sync_print_obj() is called from sync_debugfs_show(), lockdep complains<br /> inconsistent lock state warning.<br /> <br /> Use plain spin_{lock,unlock}() for sync_print_obj(), for<br /> sync_debugfs_show() is already using spin_{lock,unlock}_irq().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-mapping: benchmark: fix node id validation<br /> <br /> While validating node ids in map_benchmark_ioctl(), node_possible() may<br /> be provided with invalid argument outside of [0,MAX_NUMNODES-1] range<br /> leading to:<br /> <br /> BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)<br /> Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971<br /> CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:117)<br /> kasan_report (mm/kasan/report.c:603)<br /> kasan_check_range (mm/kasan/generic.c:189)<br /> variable_test_bit (arch/x86/include/asm/bitops.h:227) [inline]<br /> arch_test_bit (arch/x86/include/asm/bitops.h:239) [inline]<br /> _test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline]<br /> node_state (include/linux/nodemask.h:423) [inline]<br /> map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)<br /> full_proxy_unlocked_ioctl (fs/debugfs/file.c:333)<br /> __x64_sys_ioctl (fs/ioctl.c:890)<br /> do_syscall_64 (arch/x86/entry/common.c:83)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> <br /> Compare node ids with sane bounds first. NUMA_NO_NODE is considered a<br /> special valid case meaning that benchmarking kthreads won&amp;#39;t be bound to a<br /> cpuset of a given node.<br /> <br /> Found by Linux Verification Center (linuxtesting.org).

Improper Neutralization of Input During Web Page Generation (XSS or &amp;#39;Cross-site Scripting&amp;#39;) vulnerability in John West Slideshow SE allows Stored XSS.This issue affects Slideshow SE: from n/a through 2.5.17.

Improper Neutralization of Input During Web Page Generation (XSS or &amp;#39;Cross-site Scripting&amp;#39;) vulnerability in D’arteweb DImage 360 allows Stored XSS.This issue affects DImage 360: from n/a through 2.0.

Improper Neutralization of Input During Web Page Generation (XSS or &amp;#39;Cross-site Scripting&amp;#39;) vulnerability in Live Composer Team Page Builder: Live Composer allows Stored XSS.This issue affects Page Builder: Live Composer: from n/a through 1.5.42.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: Fix loop termination condition in gss_free_in_token_pages()<br /> <br /> The in_token-&gt;pages[] array is not NULL terminated. This results in<br /> the following KASAN splat:<br /> <br /> KASAN: maybe wild-memory-access in range [0x04a2013400000008-0x04a201340000000f]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soundwire: cadence: fix invalid PDI offset<br /> <br /> For some reason, we add an offset to the PDI, presumably to skip the<br /> PDI0 and PDI1 which are reserved for BPT.<br /> <br /> This code is however completely wrong and leads to an out-of-bounds<br /> access. We were just lucky so far since we used only a couple of PDIs<br /> and remained within the PDI array bounds.<br /> <br /> A Fixes: tag is not provided since there are no known platforms where<br /> the out-of-bounds would be accessed, and the initial code had problems<br /> as well.<br /> <br /> A follow-up patch completely removes this useless offset.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: multidev: fix to recognize valid zero block address<br /> <br /> As reported by Yi Zhang in mailing list [1], kernel warning was catched<br /> during zbd/010 test as below:<br /> <br /> ./check zbd/010<br /> zbd/010 (test gap zone support with F2FS) [failed]<br /> runtime ... 3.752s<br /> something found in dmesg:<br /> [ 4378.146781] run blktests zbd/010 at 2024-02-18 11:31:13<br /> [ 4378.192349] null_blk: module loaded<br /> [ 4378.209860] null_blk: disk nullb0 created<br /> [ 4378.413285] scsi_debug:sdebug_driver_probe: scsi_debug: trim<br /> poll_queues to 0. poll_q/nr_hw = (0/1)<br /> [ 4378.422334] scsi host15: scsi_debug: version 0191 [20210520]<br /> dev_size_mb=1024, opts=0x0, submit_queues=1, statistics=0<br /> [ 4378.434922] scsi 15:0:0:0: Direct-Access-ZBC Linux<br /> scsi_debug 0191 PQ: 0 ANSI: 7<br /> [ 4378.443343] scsi 15:0:0:0: Power-on or device reset occurred<br /> [ 4378.449371] sd 15:0:0:0: Attached scsi generic sg5 type 20<br /> [ 4378.449418] sd 15:0:0:0: [sdf] Host-managed zoned block device<br /> ...<br /> (See &amp;#39;/mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/zbd/010.dmesg&amp;#39;<br /> <br /> WARNING: CPU: 22 PID: 44011 at fs/iomap/iter.c:51<br /> CPU: 22 PID: 44011 Comm: fio Not tainted 6.8.0-rc3+ #1<br /> RIP: 0010:iomap_iter+0x32b/0x350<br /> Call Trace:<br /> <br /> __iomap_dio_rw+0x1df/0x830<br /> f2fs_file_read_iter+0x156/0x3d0 [f2fs]<br /> aio_read+0x138/0x210<br /> io_submit_one+0x188/0x8c0<br /> __x64_sys_io_submit+0x8c/0x1a0<br /> do_syscall_64+0x86/0x170<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> Shinichiro Kawasaki helps to analyse this issue and proposes a potential<br /> fixing patch in [2].<br /> <br /> Quoted from reply of Shinichiro Kawasaki:<br /> <br /> "I confirmed that the trigger commit is dbf8e63f48af as Yi reported. I took a<br /> look in the commit, but it looks fine to me. So I thought the cause is not<br /> in the commit diff.<br /> <br /> I found the WARN is printed when the f2fs is set up with multiple devices,<br /> and read requests are mapped to the very first block of the second device in the<br /> direct read path. In this case, f2fs_map_blocks() and f2fs_map_blocks_cached()<br /> modify map-&gt;m_pblk as the physical block address from each block device. It<br /> becomes zero when it is mapped to the first block of the device. However,<br /> f2fs_iomap_begin() assumes that map-&gt;m_pblk is the physical block address of the<br /> whole f2fs, across the all block devices. It compares map-&gt;m_pblk against<br /> NULL_ADDR == 0, then go into the unexpected branch and sets the invalid<br /> iomap-&gt;length. The WARN catches the invalid iomap-&gt;length.<br /> <br /> This WARN is printed even for non-zoned block devices, by following steps.<br /> <br /> - Create two (non-zoned) null_blk devices memory backed with 128MB size each:<br /> nullb0 and nullb1.<br /> # mkfs.f2fs /dev/nullb0 -c /dev/nullb1<br /> # mount -t f2fs /dev/nullb0 "${mount_dir}"<br /> # dd if=/dev/zero of="${mount_dir}/test.dat" bs=1M count=192<br /> # dd if="${mount_dir}/test.dat" of=/dev/null bs=1M count=192 iflag=direct<br /> <br /> ..."<br /> <br /> So, the root cause of this issue is: when multi-devices feature is on,<br /> f2fs_map_blocks() may return zero blkaddr in non-primary device, which is<br /> a verified valid block address, however, f2fs_iomap_begin() treats it as<br /> an invalid block address, and then it triggers the warning in iomap<br /> framework code.<br /> <br /> Finally, as discussed, we decide to use a more simple and direct way that<br /> checking (map.m_flags &amp; F2FS_MAP_MAPPED) condition instead of<br /> (map.m_pblk != NULL_ADDR) to fix this issue.<br /> <br /> Thanks a lot for the effort of Yi Zhang and Shinichiro Kawasaki on this<br /> issue.<br /> <br /> [1] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/<br /> [2] https://lore.kernel.org/linux-f2fs-devel/gngdj77k4picagsfdtiaa7gpgnup6fsgwzsltx6milmhegmjff@iax2n4wvrqye/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: max3100: Update uart_driver_registered on driver removal<br /> <br /> The removal of the last MAX3100 device triggers the removal of<br /> the driver. However, code doesn&amp;#39;t update the respective global<br /> variable and after insmod — rmmod — insmod cycle the kernel<br /> oopses:<br /> <br /> max3100 spi-PRP0001:01: max3100_probe: adding port 0<br /> BUG: kernel NULL pointer dereference, address: 0000000000000408<br /> ...<br /> RIP: 0010:serial_core_register_port+0xa0/0x840<br /> ...<br /> max3100_probe+0x1b6/0x280 [max3100]<br /> spi_probe+0x8d/0xb0<br /> <br /> Update the actual state so next time UART driver will be registered<br /> again.<br /> <br /> Hugo also noticed, that the error path in the probe also affected<br /> by having the variable set, and not cleared. Instead of clearing it<br /> move the assignment after the successfull uart_register_driver() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: max3100: Lock port-&gt;lock when calling uart_handle_cts_change()<br /> <br /> uart_handle_cts_change() has to be called with port lock taken,<br /> Since we run it in a separate work, the lock may not be taken at<br /> the time of running. Make sure that it&amp;#39;s taken by explicitly doing<br /> that. Without it we got a splat:<br /> <br /> WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0<br /> ...<br /> Workqueue: max3100-0 max3100_work [max3100]<br /> RIP: 0010:uart_handle_cts_change+0xa6/0xb0<br /> ...<br /> max3100_handlerx+0xc5/0x110 [max3100]<br /> max3100_work+0x12a/0x340 [max3100]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> greybus: lights: check return of get_channel_from_mode<br /> <br /> If channel for the given node is not found we return null from<br /> get_channel_from_mode. Make sure we validate the return pointer<br /> before using it in two of the missing places.<br /> <br /> This was originally reported in [0]:<br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.<br /> <br /> [0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru