Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: stub: Reject I2C block transfers with invalid length<br /> <br /> The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data-&gt;block[0]<br /> as the transfer length. The existing check only clamps it to avoid<br /> overrunning the chip-&gt;words[256] register array, but does not validate<br /> it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union<br /> i2c_smbus_data.block buffer (34 bytes total). The driver is a<br /> development/test tool (CONFIG_I2C_STUB=m, not built by default)<br /> that must be loaded with a chip_addr= parameter.<br /> <br /> A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl<br /> with I2C_SMBUS_I2C_BLOCK_DATA and data-&gt;block[0] &gt; 32, causing<br /> stub_xfer() to read or write past the end of the union<br /> i2c_smbus_data.block buffer:<br /> <br /> BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223)<br /> Read of size 1 at addr ffff88800abcfd92 by task exploit/81<br /> Call Trace:<br /> <br /> stub_xfer (drivers/i2c/i2c-stub.c:223)<br /> __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593)<br /> i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536)<br /> i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391)<br /> i2cdev_ioctl (drivers/i2c/i2c-dev.c:478)<br /> __x64_sys_ioctl (fs/ioctl.c:583)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:94)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> <br /> <br /> The bug exists because i2c-stub implements .smbus_xfer directly,<br /> bypassing the I2C_SMBUS_BLOCK_MAX validation in<br /> i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same<br /> function correctly validates against I2C_SMBUS_BLOCK_MAX, but the<br /> I2C_SMBUS_I2C_BLOCK_DATA case does not.<br /> <br /> Fix by rejecting transfers with data-&gt;block[0] == 0 or<br /> data-&gt;block[0] &gt; I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with<br /> both the I2C_SMBUS_BLOCK_DATA case in the same function and the<br /> I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized<br /> <br /> When CONFIG_BPF_LSM=y is set, BPF inode storage maps<br /> (BPF_MAP_TYPE_INODE_STORAGE) are compiled into the kernel. However,<br /> if the BPF LSM is not explicitly enabled at boot time (e.g. omitted<br /> from the "lsm=" boot parameter), lsm_prepare() is never executed for<br /> the BPF LSM.<br /> <br /> Consequently, the BPF inode security blob offset<br /> (bpf_lsm_blob_sizes.lbs_inode) is never initialized and remains at<br /> its default compiled size of 8 bytes instead of being updated to a<br /> valid offset past the reserved struct rcu_head (typically 16 bytes<br /> or more).<br /> <br /> When a privileged user creates and updates a BPF_MAP_TYPE_INODE_STORAGE<br /> map, bpf_inode() evaluates inode-&gt;i_security + 8. This erroneously<br /> aliases the struct rcu_head.func callback pointer at the beginning<br /> of the inode-&gt;i_security blob. During subsequent map element cleanup<br /> or inode destruction, writing NULL to owner_storage clears the queued<br /> RCU callback pointer. When rcu_do_batch() later executes the queued<br /> callback, it attempts an instruction fetch at address 0x0, triggering<br /> an immediate kernel panic.<br /> <br /> Fix this by introducing a global bpf_lsm_initialized boolean flag<br /> marked with __ro_after_init. Set this flag to true inside bpf_lsm_init()<br /> when the LSM framework successfully registers the BPF LSM. Gate map<br /> allocation in inode_storage_map_alloc() on this flag, returning<br /> -EOPNOTSUPP if the BPF LSM is in turn uninitialized.<br /> <br /> This fail-fast approach prevents userspace from allocating inode<br /> storage maps when the supporting BPF LSM infrastructure is absent,<br /> avoiding zombie map states.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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)

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.