Vulnerabilidades

*** Pendiente de traducción *** RT is an open source, enterprise-grade issue and ticket tracking system. Versions 6.0.0 and above, prior to 6.0.3, contain a stored Cross-Site Scripting (XSS) vulnerability, where user-controlled data is rendered without proper HTML escaping. An authenticated user with permission to set the relevant data can inject JavaScript that executes when another RT user views the affected page. This issue has been fixed in version 6.0.3.

*** Pendiente de traducción *** Chamilo version 1.11.40 and earlier are vulnerable to authenticated remote code execution in the main/inc/ajax/lang.ajax.php path. This endpoint is protected only by `api_protect_course_script(true)`, which means any authenticated user enrolled in a course (student, teacher, DRH) can reach it.

*** Pendiente de traducción *** Chamilo LMS versions 1.11.38 and earlier contain a stored cross-site scripting vulnerability in the user registration form that allows any unauthenticated attacker to execute arbitrary JavaScript in an administrator's browser session, leading to full platform admin account takeover. This has been patched in 1.11.40.

*** Pendiente de traducción *** Mettle SendPortal 3.0.1 and earlier contains a stored cross-site scripting (XSS) vulnerability in the template management functionality. The application fails to properly sanitize user-supplied input in the content parameter of the /templates endpoint, allowing an attacker to persistently inject malicious JavaScript code that is executed in the browsers of users who access the affected template.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: team: fix NULL pointer dereference in team_xmit during mode change<br /> <br /> __team_change_mode() clears team-&gt;ops with memset() before restoring<br /> safe dummy handlers via team_adjust_ops(). A concurrent team_xmit()<br /> running under RCU on another CPU can read team-&gt;ops.transmit during<br /> this window and call a NULL function pointer, crashing the kernel.<br /> <br /> The race requires a mode change (CAP_NET_ADMIN) concurrent with<br /> transmit on the team device.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> Oops: 0010 [#1] SMP KASAN NOPTI<br /> RIP: 0010:0x0<br /> Call Trace:<br /> team_xmit (drivers/net/team/team_core.c:1853)<br /> dev_hard_start_xmit (net/core/dev.c:3904)<br /> __dev_queue_xmit (net/core/dev.c:4871)<br /> packet_sendmsg (net/packet/af_packet.c:3109)<br /> __sys_sendto (net/socket.c:2265)<br /> <br /> The original code assumed that no ports means no traffic, so mode<br /> changes could freely memset()/memcpy() the ops. AF_PACKET with<br /> forced carrier breaks that assumption.<br /> <br /> Prevent the race instead of making it safe: replace memset()/memcpy()<br /> with per-field updates that never touch transmit or receive. Those<br /> two handlers are managed solely by team_adjust_ops(), which already<br /> installs dummies when tx_en_port_count == 0 (always true during mode<br /> change since no ports are present). WRITE_ONCE/READ_ONCE prevent<br /> store/load tearing on the handler pointers.<br /> <br /> synchronize_net() before exit_op() drains in-flight readers that may<br /> still reference old mode state from before port removal switched the<br /> handlers to dummies.

*** 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 /> 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 /> 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 /> 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 /> 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.