Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: i801: fix hardware state machine corruption in error path<br /> <br /> A severe livelock and subsequent Hung Task panic were observed in the<br /> i2c-i801 driver during concurrent Fuzzing. The crash is caused by an<br /> unconditional hardware register cleanup in the error handling path of<br /> i801_access().<br /> <br /> When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus<br /> controller is actively used by BIOS/ACPI), the kernel does not actually<br /> acquire the hardware ownership. However, the code jumps to the &amp;#39;out&amp;#39;<br /> label and executes:<br /> <br /> iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv));<br /> <br /> This forcefully clears the INUSE_STS lock and resets the hardware status<br /> flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI<br /> transactions and totally corrupts the SMBus hardware state machine.<br /> <br /> Consequently, all subsequent i801_access() calls fail at the pre-check<br /> stage, triggering an endless stream of "SMBus is busy, can&amp;#39;t use it!"<br /> error logs. Over a slow serial console, this printk flood monopolizes<br /> the CPU (Console Livelock), starving other processes trying to acquire<br /> the mmap_lock down_read semaphore, ultimately triggering the hung task<br /> watchdog.<br /> <br /> Fix this by moving the &amp;#39;out&amp;#39; label below the hardware register cleanup.<br /> If i801_check_pre() fails, we safely bypass the iowrite8() and only<br /> release the software locks (pm_runtime and mutex), strictly adhering to<br /> the rule of not releasing resources that were never acquired.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: cancel pending_rx_work before taking conn-&gt;lock<br /> <br /> l2cap_conn_del() takes conn-&gt;lock and then calls cancel_work_sync() for<br /> pending_rx_work. process_pending_rx() takes the same mutex, so teardown<br /> can deadlock against the worker it is flushing.<br /> <br /> This issue was found by our static analysis tool and then manually<br /> reviewed against the current tree.<br /> <br /> The grounded PoC kept the l2cap_conn_ready() -&gt; queue_work(...,<br /> &amp;conn-&gt;pending_rx_work) submit path, the l2cap_conn_del() -&gt;<br /> cancel_work_sync(&amp;conn-&gt;pending_rx_work) teardown path, and the<br /> process_pending_rx() -&gt; mutex_lock(&amp;conn-&gt;lock) worker edge. Lockdep<br /> <br /> WARNING: possible circular locking dependency detected<br /> process_pending_rx+0x21/0x2a [vuln_msv]<br /> l2cap_conn_del.constprop.0+0x3f/0x4e [vuln_msv]<br /> *** DEADLOCK ***<br /> <br /> Cancel pending_rx_work before taking conn-&gt;lock, matching the existing<br /> lock-before-drain ordering used for the two delayed works in the same<br /> teardown path. The pending_rx queue is still purged after the work has<br /> been cancelled and conn-&gt;lock has been acquired.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: dualpi2: fix GSO backlog accounting<br /> <br /> When DualPI2 splits a GSO skb into N segments, it propagates N<br /> additional packets to its parent before returning NET_XMIT_SUCCESS.<br /> The parent then accounts for the original skb once more, leaving its<br /> qlen one larger than the number of packets actually queued.<br /> <br /> With QFQ as the parent, after all real packets are dequeued, QFQ still<br /> has a non-zero qlen while its in-service aggregate has no active<br /> classes. qfq_choose_next_agg() returns NULL and qfq_dequeue() passes<br /> the result to qfq_peek_skb(), causing a NULL pointer dereference.<br /> <br /> Follow the same pattern used by tbf_segment() and taprio: count only<br /> successfully queued segments, propagate the difference between the<br /> original skb and those segments, and return NET_XMIT_SUCCESS whenever<br /> at least one segment was queued.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fail recovery on a committed log item with no regions<br /> <br /> If the first op of a transaction is a bare transaction header<br /> (len == sizeof(struct xfs_trans_header)), xlog_recover_add_to_trans()<br /> adds an item but no region, leaving it on r_itemq with ri_cnt == 0 and<br /> ri_buf == NULL.<br /> <br /> The header can be split across op records, so later ops may still add<br /> regions; the item is only invalid if the transaction commits with none.<br /> The runtime commit path never emits such a transaction, so this only<br /> happens on a crafted log. It came from an AI-assisted code audit of the<br /> recovery parser.<br /> <br /> xlog_recover_reorder_trans() calls ITEM_TYPE() on the item, which reads<br /> *(unsigned short *)item-&gt;ri_buf[0].iov_base and faults on the NULL<br /> ri_buf. Reject it there, before the commit handlers that also read<br /> ri_buf[0].<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> RIP: 0010:xlog_recover_reorder_trans (fs/xfs/xfs_log_recover.c:1836)<br /> xlog_recover_commit_trans (fs/xfs/xfs_log_recover.c:2043)<br /> xlog_recover_process_data (fs/xfs/xfs_log_recover.c:2501)<br /> xlog_do_recovery_pass (fs/xfs/xfs_log_recover.c:3244)<br /> xlog_recover (fs/xfs/xfs_log_recover.c:3493)<br /> xfs_log_mount (fs/xfs/xfs_log.c:618)<br /> xfs_mountfs (fs/xfs/xfs_mount.c:1034)<br /> xfs_fs_fill_super (fs/xfs/xfs_super.c:1938)<br /> vfs_get_tree (fs/super.c:1695)<br /> path_mount (fs/namespace.c:4161)<br /> __x64_sys_mount (fs/namespace.c:4367)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qualcomm: rmnet: fix endpoint use-after-free in rmnet_dellink()<br /> <br /> rmnet_dellink() removes the endpoint from the hash table with<br /> hlist_del_init_rcu() and then immediately frees it with kfree(). However,<br /> RCU readers on the receive path (rmnet_rx_handler -&gt;<br /> __rmnet_map_ingress_handler) may still hold a reference to the endpoint and<br /> dereference ep-&gt;egress_dev after the memory has been freed. The endpoint is<br /> a kmalloc-32 object, and the stale read at offset 8 corresponds to the<br /> egress_dev pointer.<br /> <br /> BUG: unable to handle page fault for address: ffffffffde942eef<br /> Oops: 0002 [#1] SMP NOPTI<br /> CPU: 1 UID: 0 PID: 137 Comm: poc_write Not tainted 7.0.0+ #4 PREEMPTLAZY<br /> RIP: 0010:rmnet_vnd_rx_fixup (rmnet_vnd.c:27)<br /> Call Trace:<br /> <br /> __rmnet_map_ingress_handler (rmnet_handlers.c:48 rmnet_handlers.c:101)<br /> rmnet_rx_handler (rmnet_handlers.c:129 rmnet_handlers.c:235)<br /> __netif_receive_skb_core.constprop.0 (net/core/dev.c:6096)<br /> __netif_receive_skb_one_core (net/core/dev.c:6208)<br /> netif_receive_skb (net/core/dev.c:6467)<br /> tun_get_user (drivers/net/tun.c:1955)<br /> tun_chr_write_iter (drivers/net/tun.c:2003)<br /> vfs_write (fs/read_write.c:688)<br /> ksys_write (fs/read_write.c:740)<br /> <br /> <br /> Add an rcu_head field to struct rmnet_endpoint and replace kfree() with<br /> kfree_rcu() so the endpoint memory remains valid through the RCU grace<br /> period. Also remove the rmnet_vnd_dellink() call and inline only the<br /> nr_rmnet_devs decrement, since rmnet_vnd_dellink() would set<br /> ep-&gt;egress_dev to NULL during the grace period, creating a data race<br /> with lockless readers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ipset: fix race between dump and ip_set_list resize<br /> <br /> The release path of ip_set_dump_do() and ip_set_dump_done() read<br /> inst-&gt;ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw()<br /> of the array pointer. These run from netlink_recvmsg() without the nfnl<br /> mutex and without an RCU read-side critical section.<br /> <br /> A concurrent ip_set_create() can grow the array: it publishes the new<br /> array, calls synchronize_net() and then kvfree()s the old one. Since the<br /> dump paths read the array outside any RCU reader, synchronize_net() does<br /> not wait for them and the old array can be freed while they still index<br /> into it, causing a use-after-free.<br /> <br /> The dumped set itself stays pinned via set-&gt;ref_netlink, so only the<br /> array load needs protecting. Take rcu_read_lock() around it, matching<br /> ip_set_get_byname() and __ip_set_put_byindex().<br /> <br /> BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)<br /> Read of size 8 at addr ffff88800b5c4018 by task exploit/150<br /> Call Trace:<br /> ...<br /> kasan_report (mm/kasan/report.c:595)<br /> ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697)<br /> netlink_dump (net/netlink/af_netlink.c:2325)<br /> netlink_recvmsg (net/netlink/af_netlink.c:1976)<br /> sock_recvmsg (net/socket.c:1159)<br /> __sys_recvfrom (net/socket.c:2315)<br /> ...<br /> Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI<br /> KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7]<br /> RIP: 0010:ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1698)<br /> Kernel panic - not syncing: Fatal exception

Network-AI is a TypeScript/Node.js multi-agent orchestrator. Prior to version 5.12.2, `EnvironmentManager.listBackups()` reads each backup&amp;#39;s `_manifest.json` and trusts the manifest&amp;#39;s `path` field. `EnvironmentManager.pruneBackups()` later passes that trusted `entry.path` directly to `rmSync(entry.path, { recursive: true, force: true })`. An attacker who can place or modify a manifest inside `data//.backups//_manifest.json` can cause `network-ai env backup prune --env --keep ` or any code path invoking `pruneBackups()` to recursively delete an arbitrary path accessible to the Network-AI process user. This is fixed in v5.12.2. `pruneBackups()` no longer passes `entry.path` from the on-disk manifest to `rmSync`. The deletion path is recomputed from a format-validated `entry.backupId`, and a `dirname` containment check confines deletion to exactly one level under the backups directory. A poisoned manifest (e.g. `"path": "/"`) is now inert.

Network-AI is a TypeScript/Node.js multi-agent orchestrator. Prior to version 5.12.2, `EnvironmentManager.restore(env, backupId)` computes the backup path with `join(envDir, &amp;#39;.backups&amp;#39;, backupId)` and only checks that this path exists. It does not resolve the result or verify that it remains under `data//.backups`. A caller can pass a traversal backup ID such as `../../../outside/source-dir` to restore files from an arbitrary directory into the target environment data directory. The issue is fixed in v5.12.2. `restore()` now validates `backupId` against `/^[\w\-]+$/` and asserts `dirname(resolve(join(backupsDir, backupId))) === resolve(backupsDir)` before touching the filesystem. Backup IDs containing path separators or `..` are rejected, so a crafted ID can no longer copy directories from outside `.backups/` into the environment.

Network-AI is a TypeScript/Node.js multi-agent orchestrator. Prior to version 5.12.2, `AgentRuntime` promises scoped file access under a configured sandbox `basePath`, but its path containment checks use raw string prefix tests. A sandbox base such as `/tmp/network-ai-sandbox` also matches a sibling path such as `/tmp/network-ai-sandbox_evil/secret.txt`. An agent/user that can call `AgentRuntime.readFile()` or `AgentRuntime.listDir()` can read or list files outside the intended sandbox when the target path is in a sibling directory sharing the base path prefix. This breaks the documented sandbox boundary. The issue is fixed in v5.12.2. `SandboxPolicy.resolvePath()` and `isPathAllowed()` now use separator-anchored prefix checks (`resolved === base || resolved.startsWith(base + path.sep)`) for both the allow-list and block-list. A sibling directory that merely shares a name prefix (e.g. `/srv/app-evil` vs base `/srv/app`) is no longer treated as in-scope.

Network-AI, a TypeScript/Node.js multi-agent orchestrator, has a shipped, exported, documented feature called `ApprovalInbox` (`lib/approval-inbox.ts`). It is the network surface of the human-in-the-loop Approval Gate, which `ApprovalGate` uses to require explicit human approval for high-risk operations. The HTTP server it exposes has no authentication of any kind and sets `Access-Control-Allow-Origin: *` on every route, including the state-changing `POST /approvals/:id/approve` and `/deny`. As a result, in versions 5.0.0 through 5.12.1, any party who can send an HTTP request to the inbox port — a co-located process, a container/SSRF on the same host, a remote client when the operator binds a non-loopback address, or any website the operator visits in a browser (via the wildcard CORS) — can enumerate pending approvals and approve them, defeating the entire human-in-the-loop control and causing the gated high-risk action (e.g. a shell command the agent was holding for review) to execute without consent. This issue is fixed in v5.12.2. `ApprovalInbox` now accepts a `secret` option. When set, the mutating endpoints `POST /:id/approve` and `POST /:id/deny` require an `Authorization: Bearer ` header, validated in constant time with `crypto.timingSafeEqual`. `startServer()` already binds to `127.0.0.1` by default; operators exposing the inbox on a network must set a secret.

Network-AI is a TypeScript/Node.js multi-agent orchestrator. Prior to version 5.12.2, `EnvironmentManager.backup()` recursively collects files using `_collectBackupFiles()`. `_collectBackupFiles()` uses `statSync(full)`, which follows symlinks. If `data/` contains a symlink to a directory outside the environment root, backup recursion follows the symlink and copies external files into `data//.backups//`. An attacker who can place a symlink under the environment data directory can cause backup operations to disclose files outside the environment root into backup artifacts. The issue is fixed in v5.12.2. `_collectBackupFiles()` now uses `lstatSync` instead of `statSync` and skips any entry where `isSymbolicLink()` is true. Symlinks are never traversed, so `backup()` can no longer follow a link out of the environment root and copy external files into a backup artifact.

xrdp is an open source RDP server. Versions 0.10.6 and prior contain a vulnerability concerning the processing of Client Control PDUs. During the RDP connection sequence, the parser does not perform sufficient length validation before reading specific data fields from the network stream. A remote, unauthenticated attacker could potentially exploit this flaw by sending a specially crafted, truncated Client Control PDU. Due to missing bounds checks, the xrdp process may perform out-of-bounds memory reads, which can result in the termination of the service (Denial of Service). However, since xrdp forks a new process for each connection by default, an out-of-bounds read causing a process crash is unlikely to bring down the entire xrdp service.This issue has been fixed in version 0.10.6.1.