Vulnerabilities

A vulnerability has been identified within the Rancher Backup Operator, resulting in the leakage of S3 tokens (both accessKey and secretKey) into the rancher-backup-operator pod's logs.

API endpoint for user synchronization in 2N Access Commander version 3.4.1 did not have a sufficient input validation allowing for OS command injection. <br /> This vulnerability can only be exploited after authenticating with administrator privileges.

A vulnerability was recently discovered in the rpc.mountd daemon in the nfs-utils package for Linux, that allows a NFSv3 client to escalate the<br /> privileges assigned to it in the /etc/exports file at mount time. In particular, it allows the client to access any subdirectory or subtree of an exported directory, regardless of the set file permissions, and regardless of any &amp;#39;root_squash&amp;#39; or &amp;#39;all_squash&amp;#39; attributes that would normally be expected to apply to that client.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: smscufx: properly copy ioctl memory to kernelspace<br /> <br /> The UFX_IOCTL_REPORT_DAMAGE ioctl does not properly copy data from<br /> userspace to kernelspace, and instead directly references the memory,<br /> which can cause problems if invalid data is passed from userspace. Fix<br /> this all up by correctly copying the memory before accessing it within<br /> the kernel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> romfs: check sb_set_blocksize() return value<br /> <br /> romfs_fill_super() ignores the return value of sb_set_blocksize(), which<br /> can fail if the requested block size is incompatible with the block<br /> device&amp;#39;s configuration.<br /> <br /> This can be triggered by setting a loop device&amp;#39;s block size larger than<br /> PAGE_SIZE using ioctl(LOOP_SET_BLOCK_SIZE, 32768), then mounting a romfs<br /> filesystem on that device.<br /> <br /> When sb_set_blocksize(sb, ROMBSIZE) is called with ROMBSIZE=4096 but the<br /> device has logical_block_size=32768, bdev_validate_blocksize() fails<br /> because the requested size is smaller than the device&amp;#39;s logical block<br /> size. sb_set_blocksize() returns 0 (failure), but romfs ignores this and<br /> continues mounting.<br /> <br /> The superblock&amp;#39;s block size remains at the device&amp;#39;s logical block size<br /> (32768). Later, when sb_bread() attempts I/O with this oversized block<br /> size, it triggers a kernel BUG in folio_set_bh():<br /> <br /> kernel BUG at fs/buffer.c:1582!<br /> BUG_ON(size &gt; PAGE_SIZE);<br /> <br /> Fix by checking the return value of sb_set_blocksize() and failing the<br /> mount with -EINVAL if it returns 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: classmate-laptop: Add missing NULL pointer checks<br /> <br /> In a few places in the Classmate laptop driver, code using the accel<br /> object may run before that object&amp;#39;s address is stored in the driver<br /> data of the input device using it.<br /> <br /> For example, cmpc_accel_sensitivity_store_v4() is the "show" method<br /> of cmpc_accel_sensitivity_attr_v4 which is added in cmpc_accel_add_v4(),<br /> before calling dev_set_drvdata() for inputdev-&gt;dev. If the sysfs<br /> attribute is accessed prematurely, the dev_get_drvdata(&amp;inputdev-&gt;dev)<br /> call in in cmpc_accel_sensitivity_store_v4() returns NULL which<br /> leads to a NULL pointer dereference going forward.<br /> <br /> Moreover, sysfs attributes using the input device are added before<br /> initializing that device by cmpc_add_acpi_notify_device() and if one<br /> of them is accessed before running that function, a NULL pointer<br /> dereference will occur.<br /> <br /> For example, cmpc_accel_sensitivity_attr_v4 is added before calling<br /> cmpc_add_acpi_notify_device() and if it is read prematurely, the<br /> dev_get_drvdata(&amp;acpi-&gt;dev) call in cmpc_accel_sensitivity_show_v4()<br /> returns NULL which leads to a NULL pointer dereference going forward.<br /> <br /> Fix this by adding NULL pointer checks in all of the relevant places.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix out-of-bounds access in sysfs attribute read/write<br /> <br /> Some f2fs sysfs attributes suffer from out-of-bounds memory access and<br /> incorrect handling of integer values whose size is not 4 bytes.<br /> <br /> For example:<br /> vm:~# echo 65537 &gt; /sys/fs/f2fs/vde/carve_out<br /> vm:~# cat /sys/fs/f2fs/vde/carve_out<br /> 65537<br /> vm:~# echo 4294967297 &gt; /sys/fs/f2fs/vde/atgc_age_threshold<br /> vm:~# cat /sys/fs/f2fs/vde/atgc_age_threshold<br /> 1<br /> <br /> carve_out maps to {struct f2fs_sb_info}-&gt;carve_out, which is a 8-bit<br /> integer. However, the sysfs interface allows setting it to a value<br /> larger than 255, resulting in an out-of-range update.<br /> <br /> atgc_age_threshold maps to {struct atgc_management}-&gt;age_threshold,<br /> which is a 64-bit integer, but its sysfs interface cannot correctly set<br /> values larger than UINT_MAX.<br /> <br /> The root causes are:<br /> 1. __sbi_store() treats all default values as unsigned int, which<br /> prevents updating integers larger than 4 bytes and causes out-of-bounds<br /> writes for integers smaller than 4 bytes.<br /> <br /> 2. f2fs_sbi_show() also assumes all default values are unsigned int,<br /> leading to out-of-bounds reads and incorrect access to integers larger<br /> than 4 bytes.<br /> <br /> This patch introduces {struct f2fs_attr}-&gt;size to record the actual size<br /> of the integer associated with each sysfs attribute. With this<br /> information, sysfs read and write operations can correctly access and<br /> update values according to their real data size, avoiding memory<br /> corruption and truncation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid UAF in f2fs_write_end_io()<br /> <br /> As syzbot reported an use-after-free issue in f2fs_write_end_io().<br /> <br /> It is caused by below race condition:<br /> <br /> loop device umount<br /> - worker_thread<br /> - loop_process_work<br /> - do_req_filebacked<br /> - lo_rw_aio<br /> - lo_rw_aio_complete<br /> - blk_mq_end_request<br /> - blk_update_request<br /> - f2fs_write_end_io<br /> - dec_page_count<br /> - folio_end_writeback<br /> - kill_f2fs_super<br /> - kill_block_super<br /> - f2fs_put_super<br /> : free(sbi)<br /> : get_pages(, F2FS_WB_CP_DATA)<br /> accessed sbi which is freed<br /> <br /> In kill_f2fs_super(), we will drop all page caches of f2fs inodes before<br /> call free(sbi), it guarantee that all folios should end its writeback, so<br /> it should be safe to access sbi before last folio_end_writeback().<br /> <br /> Let&amp;#39;s relocate ckpt thread wakeup flow before folio_end_writeback() to<br /> resolve this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid mapping wrong physical block for swapfile<br /> <br /> Xiaolong Guo reported a f2fs bug in bugzilla [1]<br /> <br /> [1] https://bugzilla.kernel.org/show_bug.cgi?id=220951<br /> <br /> Quoted:<br /> <br /> "When using stress-ng&amp;#39;s swap stress test on F2FS filesystem with kernel 6.6+,<br /> the system experiences data corruption leading to either:<br /> 1 dm-verity corruption errors and device reboot<br /> 2 F2FS node corruption errors and boot hangs<br /> <br /> The issue occurs specifically when:<br /> 1 Using F2FS filesystem (ext4 is unaffected)<br /> 2 Swapfile size is less than F2FS section size (2MB)<br /> 3 Swapfile has fragmented physical layout (multiple non-contiguous extents)<br /> 4 Kernel version is 6.6+ (6.1 is unaffected)<br /> <br /> The root cause is in check_swap_activate() function in fs/f2fs/data.c. When the<br /> first extent of a small swapfile (main_blkaddr) % blks_per_sec ||<br /> nr_pblocks % blks_per_sec ||<br /> !f2fs_valid_pinned_area(sbi, pblock)) {<br /> bool last_extent = false;<br /> <br /> not_aligned++;<br /> <br /> nr_pblocks = roundup(nr_pblocks, blks_per_sec);<br /> if (cur_lblock + nr_pblocks &gt; sis-&gt;max)<br /> nr_pblocks -= blks_per_sec;<br /> <br /> /* this extent is last one */<br /> if (!nr_pblocks) {<br /> nr_pblocks = last_lblock - cur_lblock;<br /> last_extent = true;<br /> }<br /> <br /> ret = f2fs_migrate_blocks(inode, cur_lblock, nr_pblocks);<br /> if (ret) {<br /> if (ret == -ENOENT)<br /> ret = -EINVAL;<br /> goto out;<br /> }<br /> <br /> if (!last_extent)<br /> goto retry;<br /> }<br /> <br /> When the first extent is unaligned and roundup(nr_pblocks, blks_per_sec)<br /> exceeds sis-&gt;max, we subtract blks_per_sec resulting in nr_pblocks = 0. The<br /> code then incorrectly assumes this is the last extent, sets nr_pblocks =<br /> last_lblock - cur_lblock (entire swapfile), and performs migration. After<br /> migration, it doesn&amp;#39;t retry mapping, so subsequent extents are never processed.<br /> "<br /> <br /> In order to fix this issue, we need to lookup block mapping info after<br /> we migrate all blocks in the tail of swapfile.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "f2fs: block cache/dio write during f2fs_enable_checkpoint()"<br /> <br /> This reverts commit 196c81fdd438f7ac429d5639090a9816abb9760a.<br /> <br /> Original patch may cause below deadlock, revert it.<br /> <br /> write remount<br /> - write_begin<br /> - lock_page --- lock A<br /> - prepare_write_begin<br /> - f2fs_map_lock<br /> - f2fs_enable_checkpoint<br /> - down_write(cp_enable_rwsem) --- lock B<br /> - sync_inode_sb<br /> - writepages<br /> - lock_page --- lock A<br /> - down_read(cp_enable_rwsem) --- lock A

Insecure permissions in App-Auto-Patch v3.4.2 create a race condition which allows attackers to write arbitrary files.

erase-install prior to v40.4 commit 2c31239 writes swiftDialog credential output to a hardcoded path /var/tmp/dialog.json. This allows an unauthenticated attacker to intercept admin credentials entered during reinstall/erase operations via creating a named pipe.