Vulnerabilidades

*** Pendiente de traducción *** A flaw was found in libefiboot, a component of efivar. The device path node parser in libefiboot fails to validate that each node's Length field is at least 4 bytes, which is the minimum size for an EFI (Extensible Firmware Interface) device path node header. A local user could exploit this vulnerability by providing a specially crafted device path node. This can lead to infinite recursion, causing stack exhaustion and a process crash, resulting in a denial of service (DoS).

*** Pendiente de traducción *** A flaw was found in InstructLab. The `linux_train.py` script hardcodes `trust_remote_code=True` when loading models from HuggingFace. This allows a remote attacker to achieve arbitrary Python code execution by convincing a user to run `ilab train/download/generate` with a specially crafted malicious model from the HuggingFace Hub. This vulnerability can lead to complete system compromise.

*** Pendiente de traducción *** A flaw was found in GNU Emacs. This vulnerability, a memory corruption issue, occurs when Emacs processes specially crafted SVG (Scalable Vector Graphics) CSS (Cascading Style Sheets) data. A local user could exploit this by convincing a victim to open a malicious SVG file, which may lead to a denial of service (DoS) or potentially information disclosure.

*** Pendiente de traducción *** An insecure direct object reference (IDOR) vulnerability in the Fullstep V5 registration process allows authenticated users to access data belonging to other registered users through various vulnerable authenticated resources in the application. The vulnerable endpoints result from: '/api/suppliers/v1/suppliers//false' to list user information; and '/#/supplier-registration/supplier-registration//2' to update your user information (personal details, documents, etc.).

*** Pendiente de traducción *** Inadequate access control in the registration process in Fullstep V5, which could allow unauthenticated users to obtain a valid JWT token with which to interact with authenticated API resources. Successful exploitation of this vulnerability could allow an unauthenticated attacker to compromise the confidentiality of the affected resource, provided they have a valid token with which to interact with the API.

*** Pendiente de traducción *** PackageKit is a a D-Bus abstraction layer that allows the user to manage packages in a secure way using a cross-distro, cross-architecture API. PackageKit between and including versions 1.0.2 and 1.3.4 is vulnerable to a time-of-check time-of-use (TOCTOU) race condition on transaction flags that allows unprivileged users to install packages as root and thus leads to a local privilege escalation. This is patched in version 1.3.5.<br /> <br /> A local unprivileged user can install arbitrary RPM packages as root, including executing RPM scriptlets, without authentication. The vulnerability is a TOCTOU race condition on `transaction-&gt;cached_transaction_flags` combined with a silent state-machine guard that discards illegal backward transitions while leaving corrupted flags in place. Three bugs exist in `src/pk-transaction.c`:<br /> 1. Unconditional flag overwrite (line 4036): `InstallFiles()` writes caller-supplied flags to `transaction-&gt;cached_transaction_flags` without checking whether the transaction has already been authorized/started. A second call blindly overwrites the flags even while the transaction is RUNNING.<br /> 2. Silent state-transition rejection (lines 873–882): `pk_transaction_set_state()` silently discards backward state transitions (e.g. `RUNNING` → `WAITING_FOR_AUTH`) but the flag overwrite at step 1 already happened. The transaction continues running with corrupted flags.<br /> 3. Late flag read at execution time (lines 2273–2277): The scheduler&amp;#39;s idle callback reads cached_transaction_flags at dispatch time, not at authorization time. If flags were overwritten between authorization and execution, the backend sees the attacker&amp;#39;s flags.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Make sure to use pmu_ctx-&gt;pmu for groups<br /> <br /> Oliver reported that x86_pmu_del() ended up doing an out-of-bound memory access<br /> when group_sched_in() fails and needs to roll back.<br /> <br /> This *should* be handled by the transaction callbacks, but he found that when<br /> the group leader is a software event, the transaction handlers of the wrong PMU<br /> are used. Despite the move_group case in perf_event_open() and group_sched_in()<br /> using pmu_ctx-&gt;pmu.<br /> <br /> Turns out, inherit uses event-&gt;pmu to clone the events, effectively undoing the<br /> move_group case for all inherited contexts. Fix this by also making inherit use<br /> pmu_ctx-&gt;pmu, ensuring all inherited counters end up in the same pmu context.<br /> <br /> Similarly, __perf_event_read() should use equally use pmu_ctx-&gt;pmu for the<br /> group case.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/region: Fix leakage in __construct_region()<br /> <br /> Failing the first sysfs_update_group() needs to explicitly<br /> kfree the resource as it is too early for cxl_region_iomem_release()<br /> to do so.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/port: Fix use after free of parent_port in cxl_detach_ep()<br /> <br /> cxl_detach_ep() is called during bottom-up removal when all CXL memory<br /> devices beneath a switch port have been removed. For each port in the<br /> hierarchy it locks both the port and its parent, removes the endpoint,<br /> and if the port is now empty, marks it dead and unregisters the port<br /> by calling delete_switch_port(). There are two places during this work<br /> where the parent_port may be used after freeing:<br /> <br /> First, a concurrent detach may have already processed a port by the<br /> time a second worker finds it via bus_find_device(). Without pinning<br /> parent_port, it may already be freed when we discover port-&gt;dead and<br /> attempt to unlock the parent_port. In a production kernel that&amp;#39;s a<br /> silent memory corruption, with lock debug, it looks like this:<br /> <br /> []DEBUG_LOCKS_WARN_ON(__owner_task(owner) != get_current())<br /> []WARNING: kernel/locking/mutex.c:949 at __mutex_unlock_slowpath+0x1ee/0x310<br /> []Call Trace:<br /> []mutex_unlock+0xd/0x20<br /> []cxl_detach_ep+0x180/0x400 [cxl_core]<br /> []devm_action_release+0x10/0x20<br /> []devres_release_all+0xa8/0xe0<br /> []device_unbind_cleanup+0xd/0xa0<br /> []really_probe+0x1a6/0x3e0<br /> <br /> Second, delete_switch_port() releases three devm actions registered<br /> against parent_port. The last of those is unregister_port() and it<br /> calls device_unregister() on the child port, which can cascade. If<br /> parent_port is now also empty the device core may unregister and free<br /> it too. So by the time delete_switch_port() returns, parent_port may<br /> be free, and the subsequent device_unlock(&amp;parent_port-&gt;dev) operates<br /> on freed memory. The kernel log looks same as above, with a different<br /> offset in cxl_detach_ep().<br /> <br /> Both of these issues stem from the absence of a lifetime guarantee<br /> between a child port and its parent port.<br /> <br /> Establish a lifetime rule for ports: child ports hold a reference to<br /> their parent device until release. Take the reference when the port<br /> is allocated and drop it when released. This ensures the parent is<br /> valid for the full lifetime of the child and eliminates the use after<br /> free window in cxl_detach_ep().<br /> <br /> This is easily reproduced with a reload of cxl_acpi in QEMU with CXL<br /> devices present.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: magicmouse: avoid memory leak in magicmouse_report_fixup()<br /> <br /> The magicmouse_report_fixup() function was returning a<br /> newly kmemdup()-allocated buffer, but never freeing it.<br /> <br /> The caller of report_fixup() does not take ownership of the returned<br /> pointer, but it *is* permitted to return a sub-portion of the input<br /> rdesc, whose lifetime is managed by the caller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: ensure we&amp;#39;re polling a polled queue<br /> <br /> A user can change the polled queue count at run time. There&amp;#39;s a brief<br /> window during a reset where a hipri task may try to poll that queue<br /> before the block layer has updated the queue maps, which would race with<br /> the now interrupt driven queue and may cause double completions.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: asus: avoid memory leak in asus_report_fixup()<br /> <br /> The asus_report_fixup() function was returning a newly allocated<br /> kmemdup()-allocated buffer, but never freeing it. Switch to<br /> devm_kzalloc() to ensure the memory is managed and freed automatically<br /> when the device is removed.<br /> <br /> The caller of report_fixup() does not take ownership of the returned<br /> pointer, but it is permitted to return a pointer whose lifetime is at<br /> least that of the input buffer.<br /> <br /> Also fix a harmless out-of-bounds read by copying only the original<br /> descriptor size.