Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: Verify inode mode when loading from disk<br /> <br /> syzbot is reporting that S_IFMT bits of inode-&gt;i_mode can become bogus when<br /> the S_IFMT bits of the 16bits "mode" field loaded from disk are corrupted.<br /> <br /> According to [1], the permissions field was treated as reserved in Mac OS<br /> 8 and 9. According to [2], the reserved field was explicitly initialized<br /> with 0, and that field must remain 0 as long as reserved. Therefore, when<br /> the "mode" field is not 0 (i.e. no longer reserved), the file must be<br /> S_IFDIR if dir == 1, and the file must be one of S_IFREG/S_IFLNK/S_IFCHR/<br /> S_IFBLK/S_IFIFO/S_IFSOCK if dir == 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix return value of f2fs_recover_fsync_data()<br /> <br /> With below scripts, it will trigger panic in f2fs:<br /> <br /> mkfs.f2fs -f /dev/vdd<br /> mount /dev/vdd /mnt/f2fs<br /> touch /mnt/f2fs/foo<br /> sync<br /> echo 111 &gt;&gt; /mnt/f2fs/foo<br /> f2fs_io fsync /mnt/f2fs/foo<br /> f2fs_io shutdown 2 /mnt/f2fs<br /> umount /mnt/f2fs<br /> mount -o ro,norecovery /dev/vdd /mnt/f2fs<br /> or<br /> mount -o ro,disable_roll_forward /dev/vdd /mnt/f2fs<br /> <br /> F2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 0<br /> F2FS-fs (vdd): Mounted with checkpoint version = 7f5c361f<br /> F2FS-fs (vdd): Stopped filesystem due to reason: 0<br /> F2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 1<br /> Filesystem f2fs get_tree() didn&amp;#39;t set fc-&gt;root, returned 1<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/super.c:1761!<br /> Oops: invalid opcode: 0000 [#1] SMP PTI<br /> CPU: 3 UID: 0 PID: 722 Comm: mount Not tainted 6.18.0-rc2+ #721 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:vfs_get_tree.cold+0x18/0x1a<br /> Call Trace:<br /> <br /> fc_mount+0x13/0xa0<br /> path_mount+0x34e/0xc50<br /> __x64_sys_mount+0x121/0x150<br /> do_syscall_64+0x84/0x800<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fa6cc126cfe<br /> <br /> The root cause is we missed to handle error number returned from<br /> f2fs_recover_fsync_data() when mounting image w/ ro,norecovery or<br /> ro,disable_roll_forward mount option, result in returning a positive<br /> error number to vfs_get_tree(), fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix kernel BUG in ocfs2_find_victim_chain<br /> <br /> syzbot reported a kernel BUG in ocfs2_find_victim_chain() because the<br /> `cl_next_free_rec` field of the allocation chain list (next free slot in<br /> the chain list) is 0, triggring the BUG_ON(!cl-&gt;cl_next_free_rec)<br /> condition in ocfs2_find_victim_chain() and panicking the kernel.<br /> <br /> To fix this, an if condition is introduced in ocfs2_claim_suballoc_bits(),<br /> just before calling ocfs2_find_victim_chain(), the code block in it being<br /> executed when either of the following conditions is true:<br /> <br /> 1. `cl_next_free_rec` is equal to 0, indicating that there are no free<br /> chains in the allocation chain list<br /> 2. `cl_next_free_rec` is greater than `cl_count` (the total number of<br /> chains in the allocation chain list)<br /> <br /> Either of them being true is indicative of the fact that there are no<br /> chains left for usage.<br /> <br /> This is addressed using ocfs2_error(), which prints<br /> the error log for debugging purposes, rather than panicking the kernel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: fsl-cpm: Check length parity before switching to 16 bit mode<br /> <br /> Commit fc96ec826bce ("spi: fsl-cpm: Use 16 bit mode for large transfers<br /> with even size") failed to make sure that the size is really even<br /> before switching to 16 bit mode. Until recently the problem went<br /> unnoticed because kernfs uses a pre-allocated bounce buffer of size<br /> PAGE_SIZE for reading EEPROM.<br /> <br /> But commit 8ad6249c51d0 ("eeprom: at25: convert to spi-mem API")<br /> introduced an additional dynamically allocated bounce buffer whose size<br /> is exactly the size of the transfer, leading to a buffer overrun in<br /> the fsl-cpm driver when that size is odd.<br /> <br /> Add the missing length parity verification and remain in 8 bit mode<br /> when the length is not even.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: fix missing hfs_bnode_get() in __hfs_bnode_create<br /> <br /> When sync() and link() are called concurrently, both threads may<br /> enter hfs_bnode_find() without finding the node in the hash table<br /> and proceed to create it.<br /> <br /> Thread A:<br /> hfsplus_write_inode()<br /> -&gt; hfsplus_write_system_inode()<br /> -&gt; hfs_btree_write()<br /> -&gt; hfs_bnode_find(tree, 0)<br /> -&gt; __hfs_bnode_create(tree, 0)<br /> <br /> Thread B:<br /> hfsplus_create_cat()<br /> -&gt; hfs_brec_insert()<br /> -&gt; hfs_bnode_split()<br /> -&gt; hfs_bmap_alloc()<br /> -&gt; hfs_bnode_find(tree, 0)<br /> -&gt; __hfs_bnode_create(tree, 0)<br /> <br /> In this case, thread A creates the bnode, sets refcnt=1, and hashes it.<br /> Thread B also tries to create the same bnode, notices it has already<br /> been inserted, drops its own instance, and uses the hashed one without<br /> getting the node.<br /> <br /> ```<br /> <br /> node2 = hfs_bnode_findhash(tree, cnid);<br /> if (!node2) { next_hash = tree-&gt;node_hash[hash];<br /> tree-&gt;node_hash[hash] = node;<br /> tree-&gt;node_hash_cnt++;<br /> } else { hash_lock);<br /> kfree(node);<br /> wait_event(node2-&gt;lock_wq,<br /> !test_bit(HFS_BNODE_NEW, &amp;node2-&gt;flags));<br /> return node2;<br /> }<br /> ```<br /> <br /> However, hfs_bnode_find() requires each call to take a reference.<br /> Here both threads end up setting refcnt=1. When they later put the node,<br /> this triggers:<br /> <br /> BUG_ON(!atomic_read(&amp;node-&gt;refcnt))<br /> <br /> In this scenario, Thread B in fact finds the node in the hash table<br /> rather than creating a new one, and thus must take a reference.<br /> <br /> Fix this by calling hfs_bnode_get() when reusing a bnode newly created by<br /> another thread to ensure the refcount is updated correctly.<br /> <br /> A similar bug was fixed in HFS long ago in commit<br /> a9dc087fd3c4 ("fix missing hfs_bnode_get() in __hfs_bnode_create")<br /> but the same issue remained in HFS+ until now.

A flaw was found in Eclipse Che che-machine-exec. This vulnerability allows unauthenticated remote arbitrary command execution and secret exfiltration (SSH keys, tokens, etc.) from other users&amp;#39; Developer Workspace containers, via an unauthenticated JSON-RPC / websocket API exposed on TCP port 3333.

An issue in Semantic machines v5.4.8 allows attackers to bypass authentication via sending a crafted HTTP request to various API endpoints.

An arbitrary file upload vulnerability in the /utils/uploadFile component of Hubert Imoveis e Administracao Ltda Hub v2.0 1.27.3 allows attackers to execute arbitrary code via uploading a crafted PDF file.

fabricators Ltd Vanilla OS 2 Core image v1.1.0 was discovered to contain static keys for the SSH service, allowing attackers to possibly execute a man-in-the-middle attack during connections with other hosts.

Improper Neutralization of Special Elements used in a Command (&amp;#39;Command Injection&amp;#39;) vulnerability in Vivotek Affected device model numbers are FD8365, FD8365v2, FD9165, FD9171, FD9187, FD9189, FD9365, FD9371, FD9381, FD9387, FD9389, FD9391,FE9180,FE9181, FE9191, FE9381, FE9382, FE9391, FE9582, IB9365, IB93587LPR, IB9371,IB9381, IB9387, IB9389, IB939,IP9165,IP9171, IP9172, IP9181, IP9191, IT9389, MA9321, MA9322, MS9321, MS9390, TB9330 (Firmware modules) allows OS Command Injection.This issue affects Affected device model numbers are FD8365, FD8365v2, FD9165, FD9171, FD9187, FD9189, FD9365, FD9371, FD9381, FD9387, FD9389, FD9391,FE9180,FE9181, FE9191, FE9381, FE9382, FE9391, FE9582, IB9365, IB93587LPR, IB9371,IB9381, IB9387, IB9389, IB939,IP9165,IP9171, IP9172, IP9181, IP9191, IT9389, MA9321, MA9322, MS9321, MS9390, TB9330: 0100a, 0106a, 0106b, 0107a, 0107b_1, 0109a, 0112a, 0113a, 0113d, 0117b, 0119e, 0120b, 0121, 0121d, 0121d_48573_1, 0122e, 0124d_48573_1, 012501, 012502, 0125c.

A vulnerability has been identified in the installation/uninstallation of the Nessus Agent Tray App on Windows Hosts which could lead to escalation of privileges.

A CORS misconfiguration in Eramba Community and Enterprise Editions v3.26.0 allows an attacker-controlled Origin header to be reflected in the Access-Control-Allow-Origin response along with Access-Control-Allow-Credentials: true. This permits malicious third-party websites to perform authenticated cross-origin requests against the Eramba API, including endpoints like /system-api/login and /system-api/user/me. The response includes sensitive user session data (ID, name, email, access groups), which is accessible to the attacker&amp;#39;s JavaScript. This flaw enables full session hijack and data exfiltration without user interaction. Eramba versions 3.23.3 and earlier were tested and appear unaffected. The vulnerability is present in default installations, requiring no custom configuration.