Vulnerabilities

A vulnerability was found in Facile Sistemas Cloud Apps up to 20250107. It has been classified as problematic. Affected is an unknown function of the file /account/forgotpassword of the component Password Reset Handler. The manipulation of the argument reterros leads to cross site scripting. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability was found in Mobotix M15 4.3.4.83 and classified as problematic. This issue affects some unknown processing of the file /control/player?center&eventlist&pda&dummy_for_reload=1736177631&p_evt. The manipulation of the argument p_qual leads to cross site scripting. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability has been found in Union Bank of India Vyom 8.0.34 on Android and classified as problematic. This vulnerability affects unknown code of the component Rooting Detection. The manipulation leads to protection mechanism failure. The attack needs to be approached locally. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

IBM Sterling Secure Proxy 6.0.0.0, 6.0.0.1, 6.0.0.2, 6.0.0.3, 6.1.0.0, and 6.2.0.0 could allow a privileged user to inject commands into the underlying operating system due to improper validation of a specified type of input.

IBM TXSeries for Multiplatforms 10.1 is vulnerable to a denial of service, caused by improper enforcement of the timeout on individual read operations. By conducting a slowloris-type attacks, a remote attacker could exploit this vulnerability to cause a denial of service.

IBM TXSeries for Multiplatforms 10.1 could allow a remote attacker to cause a denial of service using persistent connections due to improper allocation of resources.

IBM Sterling Secure Proxy 6.0.0.0, 6.0.0.1, 6.0.0.2, 6.0.0.3, 6.1.0.0, and 6.2.0.0 could allow an unauthorized attacker to retrieve or alter sensitive information contents due to incorrect permission assignments.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm array: fix releasing a faulty array block twice in dm_array_cursor_end<br /> <br /> When dm_bm_read_lock() fails due to locking or checksum errors, it<br /> releases the faulty block implicitly while leaving an invalid output<br /> pointer behind. The caller of dm_bm_read_lock() should not operate on<br /> this invalid dm_block pointer, or it will lead to undefined result.<br /> For example, the dm_array_cursor incorrectly caches the invalid pointer<br /> on reading a faulty array block, causing a double release in<br /> dm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put().<br /> <br /> Reproduce steps:<br /> <br /> 1. initialize a cache device<br /> <br /> dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"<br /> dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"<br /> dmsetup create corig --table "0 524288 linear /dev/sdc $262144"<br /> dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1<br /> dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"<br /> <br /> 2. wipe the second array block offline<br /> <br /> dmsteup remove cache cmeta cdata corig<br /> mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \<br /> 2&gt;/dev/null | hexdump -e &amp;#39;1/8 "%u\n"&amp;#39;)<br /> ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \<br /> 2&gt;/dev/null | hexdump -e &amp;#39;1/8 "%u\n"&amp;#39;)<br /> dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock<br /> <br /> 3. try reopen the cache device<br /> <br /> dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"<br /> dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"<br /> dmsetup create corig --table "0 524288 linear /dev/sdc $262144"<br /> dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \<br /> /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"<br /> <br /> Kernel logs:<br /> <br /> (snip)<br /> device-mapper: array: array_block_check failed: blocknr 0 != wanted 10<br /> device-mapper: block manager: array validator check failed for block 10<br /> device-mapper: array: get_ablock failed<br /> device-mapper: cache metadata: dm_array_cursor_next for mapping failed<br /> ------------[ cut here ]------------<br /> kernel BUG at drivers/md/dm-bufio.c:638!<br /> <br /> Fix by setting the cached block pointer to NULL on errors.<br /> <br /> In addition to the reproducer described above, this fix can be<br /> verified using the "array_cursor/damaged" test in dm-unit:<br /> dm-unit run /pdata/array_cursor/damaged --kernel-dir

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Add a lock when accessing the buddy trim function<br /> <br /> When running YouTube videos and Steam games simultaneously,<br /> the tester found a system hang / race condition issue with<br /> the multi-display configuration setting. Adding a lock to<br /> the buddy allocator&amp;#39;s trim function would be the solution.<br /> <br /> <br /> [ 7197.250436] general protection fault, probably for non-canonical address 0xdead000000000108<br /> [ 7197.250447] RIP: 0010:__alloc_range+0x8b/0x340 [amddrm_buddy]<br /> [ 7197.250470] Call Trace:<br /> [ 7197.250472] <br /> [ 7197.250475] ? show_regs+0x6d/0x80<br /> [ 7197.250481] ? die_addr+0x37/0xa0<br /> [ 7197.250483] ? exc_general_protection+0x1db/0x480<br /> [ 7197.250488] ? drm_suballoc_new+0x13c/0x93d [drm_suballoc_helper]<br /> [ 7197.250493] ? asm_exc_general_protection+0x27/0x30<br /> [ 7197.250498] ? __alloc_range+0x8b/0x340 [amddrm_buddy]<br /> [ 7197.250501] ? __alloc_range+0x109/0x340 [amddrm_buddy]<br /> [ 7197.250506] amddrm_buddy_block_trim+0x1b5/0x260 [amddrm_buddy]<br /> [ 7197.250511] amdgpu_vram_mgr_new+0x4f5/0x590 [amdgpu]<br /> [ 7197.250682] amdttm_resource_alloc+0x46/0xb0 [amdttm]<br /> [ 7197.250689] ttm_bo_alloc_resource+0xe4/0x370 [amdttm]<br /> [ 7197.250696] amdttm_bo_validate+0x9d/0x180 [amdttm]<br /> [ 7197.250701] amdgpu_bo_pin+0x15a/0x2f0 [amdgpu]<br /> [ 7197.250831] amdgpu_dm_plane_helper_prepare_fb+0xb2/0x360 [amdgpu]<br /> [ 7197.251025] ? try_wait_for_completion+0x59/0x70<br /> [ 7197.251030] drm_atomic_helper_prepare_planes.part.0+0x2f/0x1e0<br /> [ 7197.251035] drm_atomic_helper_prepare_planes+0x5d/0x70<br /> [ 7197.251037] drm_atomic_helper_commit+0x84/0x160<br /> [ 7197.251040] drm_atomic_nonblocking_commit+0x59/0x70<br /> [ 7197.251043] drm_mode_atomic_ioctl+0x720/0x850<br /> [ 7197.251047] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10<br /> [ 7197.251049] drm_ioctl_kernel+0xb9/0x120<br /> [ 7197.251053] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 7197.251056] drm_ioctl+0x2d4/0x550<br /> [ 7197.251058] ? __pfx_drm_mode_atomic_ioctl+0x10/0x10<br /> [ 7197.251063] amdgpu_drm_ioctl+0x4e/0x90 [amdgpu]<br /> [ 7197.251186] __x64_sys_ioctl+0xa0/0xf0<br /> [ 7197.251190] x64_sys_call+0x143b/0x25c0<br /> [ 7197.251193] do_syscall_64+0x7f/0x180<br /> [ 7197.251197] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 7197.251199] ? amdgpu_display_user_framebuffer_create+0x215/0x320 [amdgpu]<br /> [ 7197.251329] ? drm_internal_framebuffer_create+0xb7/0x1a0<br /> [ 7197.251332] ? srso_alias_return_thunk+0x5/0xfbef5<br /> <br /> (cherry picked from commit 3318ba94e56b9183d0304577c74b33b6b01ce516)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zlib: fix avail_in bytes for s390 zlib HW compression path<br /> <br /> Since the input data length passed to zlib_compress_folios() can be<br /> arbitrary, always setting strm.avail_in to a multiple of PAGE_SIZE may<br /> cause read-in bytes to exceed the input range. Currently this triggers<br /> an assert in btrfs_compress_folios() on the debug kernel (see below).<br /> Fix strm.avail_in calculation for S390 hardware acceleration path.<br /> <br /> assertion failed: *total_in 0000021761df6538: 0707 bcr 0,%r7<br /> 0000021761df653a: 0707 bcr 0,%r7<br /> 0000021761df653c: 0707 bcr 0,%r7<br /> 0000021761df653e: 0707 bcr 0,%r7<br /> 0000021761df6540: c004004bb7ec brcl 0,000002176276d518<br /> Call Trace:<br /> [] btrfs_compress_folios+0x198/0x1a0<br /> ([] btrfs_compress_folios+0x194/0x1a0)<br /> [] compress_file_range+0x3b8/0x6d0<br /> [] btrfs_work_helper+0x10c/0x160<br /> [] process_one_work+0x2b0/0x5d0<br /> [] worker_thread+0x20e/0x3e0<br /> [] kthread+0x15a/0x170<br /> [] __ret_from_fork+0x3c/0x60<br /> [] ret_from_fork+0xa/0x38<br /> INFO: lockdep is turned off.<br /> Last Breaking-Event-Address:<br /> [] _printk+0x4c/0x58<br /> Kernel panic - not syncing: Fatal exception: panic_on_oops

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix enomem handling in buffered reads<br /> <br /> If netfs_read_to_pagecache() gets an error from either -&gt;prepare_read() or<br /> from netfs_prepare_read_iterator(), it needs to decrement -&gt;nr_outstanding,<br /> cancel the subrequest and break out of the issuing loop. Currently, it<br /> only does this for two of the cases, but there are two more that aren&amp;#39;t<br /> handled.<br /> <br /> Fix this by moving the handling to a common place and jumping to it from<br /> all four places. This is in preference to inserting a wrapper around<br /> netfs_prepare_read_iterator() as proposed by Dmitry Antipov[1].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: relax assertions on failure to encode file handles<br /> <br /> Encoding file handles is usually performed by a filesystem &gt;encode_fh()<br /> method that may fail for various reasons.<br /> <br /> The legacy users of exportfs_encode_fh(), namely, nfsd and<br /> name_to_handle_at(2) syscall are ready to cope with the possibility<br /> of failure to encode a file handle.<br /> <br /> There are a few other users of exportfs_encode_{fh,fid}() that<br /> currently have a WARN_ON() assertion when -&gt;encode_fh() fails.<br /> Relax those assertions because they are wrong.<br /> <br /> The second linked bug report states commit 16aac5ad1fa9 ("ovl: support<br /> encoding non-decodable file handles") in v6.6 as the regressing commit,<br /> but this is not accurate.<br /> <br /> The aforementioned commit only increases the chances of the assertion<br /> and allows triggering the assertion with the reproducer using overlayfs,<br /> inotify and drop_caches.<br /> <br /> Triggering this assertion was always possible with other filesystems and<br /> other reasons of -&gt;encode_fh() failures and more particularly, it was<br /> also possible with the exact same reproducer using overlayfs that is<br /> mounted with options index=on,nfs_export=on also on kernels