Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_api: fix TOCTOU NULL deref on a-&gt;goto_chain<br /> <br /> tcf_action_exec() handles TC_ACT_GOTO_CHAIN by first checking<br /> rcu_access_pointer(a-&gt;goto_chain) and then calling<br /> tcf_action_goto_chain_exec(), which does a second, independent<br /> rcu_dereference_bh(a-&gt;goto_chain) read and immediately dereferences<br /> chain-&gt;filter_chain. A concurrent tcf_action_set_ctrlact() (e.g. the gact<br /> replace path) can clear a-&gt;goto_chain between the two reads, so the second<br /> read returns NULL and tcf_action_goto_chain_exec() dereferences NULL.<br /> <br /> Fix the race by doing a single rcu_dereference_bh() read of a-&gt;goto_chain<br /> in tcf_action_exec(), checking it once for NULL, and passing the resulting<br /> chain pointer into tcf_action_goto_chain_exec(). This turns the split<br /> check/use into a single check/use on one value.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: cls_bpf: reject dev-bound programs bound to a different device<br /> <br /> cls_bpf_prog_from_efd() obtained a SCHED_CLS program via<br /> bpf_prog_get_type_dev() but never verified that a device-bound (offloaded)<br /> program&amp;#39;s bound netdev matches the TC netdev the classifier is being<br /> attached to. This let a program loaded with prog_ifindex for device A be<br /> attached via cls_bpf + skip_sw to device B; deleting device A then<br /> destroyed the program&amp;#39;s offload state while it was still attached to<br /> device B, triggering a netdevsim WARN (panic with panic_on_warn=1).<br /> <br /> Mirror the XDP attach path (net/core/dev.c) and reject the attach with<br /> -EINVAL when a dev-bound program&amp;#39;s bound device does not match the<br /> target device.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG<br /> <br /> On the packet reception path, the ID of the MAC Port on which the packet<br /> was received, is embedded in the RX DMA Descriptor&amp;#39;s metadata. The ID is<br /> extracted using the helper function cppi5_desc_get_tags_ids() which fills<br /> in the 16-bit Source Tag into the &amp;#39;port_id&amp;#39; variable. However, it is only<br /> the lower 8-bits of the 16-bit Source Tag that represent the MAC Port ID,<br /> while the upper 8-bits are Hardware-Reserved and carry an arbitrary value.<br /> With the existing logic, sporadic kernel crash is observed due to the<br /> subsequent driver code accessing out-of-bound memory because of an invalid<br /> port_id.<br /> <br /> Hence, fix the port_id extraction logic to use only the lower 8-bits of the<br /> Source Tag as the MAC Port ID.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: cls_u32: skip hash tables in u32_bind_class()<br /> <br /> u32_walk() enumerates both struct tc_u_hnode and struct tc_u_knode<br /> through the walker callback. u32_bind_class() unconditionally casts the<br /> passed fh to tc_u_knode and accesses &amp;n-&gt;res, so when fh is actually a<br /> tc_u_hnode, which has no tcf_result member, this results in a<br /> slab-out-of-bounds read of res-&gt;classid in tc_cls_bind_class().<br /> <br /> The issue can be reproduced with the following commands:<br /> <br /> tc qdisc add dev lo root handle 1: hfsc<br /> tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit<br /> tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1<br /> tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit<br /> <br /> Fix this by skipping hash tables via the TC_U32_KEY(handle) check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling<br /> <br /> In non-MSI-X mode (such as legacy INTx or single MSI), wx-&gt;msix_entry is<br /> not allocated or initialized. Calling NGBE_INTR_MISC(wx) dereferences<br /> wx-&gt;msix_entry-&gt;entry, leading to a NULL pointer dereference crash.<br /> <br /> This issue was introduced by fixing the IRQ vector when the number of<br /> VFs is 7. Fix the issue by explicitly checking `pdev-&gt;msix_enabled` to<br /> determine the correct vector index.<br /> <br /> Additionally, as a side fix, set the interrupt mask to BIT(0) for the<br /> non-MSI-X fallback. In MSI/INTx mode, the MISC and queue interrupts<br /> share vector 0, and the WX_PX_MISC_IVAR register is only valid in the<br /> MSI-X case. Thus, BIT(0) is the correct mask for the miscellaneous cause<br /> when MSI-X is disabled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> veth: fix queue index used to wake the peer txq in veth_poll<br /> <br /> veth_poll() derives the index of the peer TX queue to wake from<br /> rq-&gt;xdp_rxq.queue_index. That field is only initialized by<br /> xdp_rxq_info_reg() in veth_enable_xdp_range(), which runs only when an<br /> XDP program is attached. On the plain GRO/NAPI path<br /> (veth_napi_enable_range()) xdp_rxq_info_reg() is never called, so<br /> queue_index stays 0 for every queue, as priv-&gt;rq is zero-allocated.<br /> <br /> So in a multi-queue setup with GRO enabled and no XDP program attached,<br /> every NAPI instance looks at the peer&amp;#39;s TX queue 0. If veth_xmit() stops<br /> peer TX queue 1 because the ptr_ring is full (NETDEV_TX_BUSY), nothing<br /> ever wakes it again: the poller draining queue 1 wakes queue 0 instead.<br /> veth implements no ndo_tx_timeout, so the netdev watchdog does not kick<br /> in either, and the queue stays stopped indefinitely.<br /> <br /> Derive the index from the position of the rq within priv-&gt;rq instead,<br /> which is correct regardless of whether XDP was ever enabled.<br /> <br /> Scripts to reproduce the stall are available at<br /> https://github.com/netoptimizer/veth-backpressure-performance-testing

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firewire: ohci: fix NULL pointer dereference in ar_context_release<br /> <br /> During the error handling path of the driver&amp;#39;s probe function, a NULL<br /> pointer dereference can occur in ar_context_release().<br /> <br /> When pci_probe() fails early (e.g., if pcim_enable_device() or MMIO mapping<br /> fails), the devres cleanup mechanism invokes release_ohci(). This function<br /> unconditionally calls ar_context_release() to clean up the asynchronous<br /> receive contexts. However, if ar_context_init() was not yet called,<br /> ctx-&gt;ohci remains NULL (as the fw_ohci structure is zero-initialized by<br /> devres_alloc()).<br /> <br /> ar_context_release() immediately dereferences ctx-&gt;ohci to get the dev<br /> pointer before checking if the context was actually initialized, leading to<br /> a crash:<br /> <br /> Oops: general protection fault, probably for non-canonical address<br /> 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]<br /> RIP: 0010:ar_context_release+0x3f/0x380 drivers/firewire/ohci.c:543<br /> Call Trace:<br /> release_ohci+0x3f/0x60 drivers/firewire/ohci.c:3567<br /> release_nodes drivers/base/devres.c:546 [inline]<br /> devres_release_all+0x1a8/0x260 drivers/base/devres.c:576<br /> device_unbind_cleanup drivers/base/dd.c:597 [inline]<br /> really_probe+0x451/0xae0 drivers/base/dd.c:772<br /> <br /> To fix this, move the assignment of the dev pointer after the !ctx-&gt;buffer<br /> check. If ctx-&gt;buffer is NULL, it indicates that the context was never<br /> successfully initialized and there is nothing to release, safely avoiding<br /> the dereference of the uninitialized ctx-&gt;ohci pointer.

*** Pendiente de traducción *** kas is a setup tool for bitbake based projects. Prior to 5.4, internal SSH key setup triggered by SSH_PRIVATE_KEY or SSH_PRIVATE_KEY_FILE creates ~/.ssh/config when no user-specific SSH configuration exists and adds a global Host * rule containing StrictHostKeyChecking no. In kas/libcmds.py, ssh_no_host_key_check() runs without checking ctx.managed_env, so the setting persists after kas exits and affects future SSH sessions by the same local user, extending beyond the intended short-lived continuous integration environment. A later SSH connection can therefore accept an attacker-controlled host key without verification, increasing the risk of a man-in-the-middle attack that compromises session confidentiality or integrity. This issue is fixed in version 5.4.

*** Pendiente de traducción *** IzPack is a widely used tool for packaging applications on the Java platform as cross-platform installers. In 5.2.6 and earlier, UnpackerBase.unpack() in izpack-installer/src/main/java/com/izforge/izpack/installer/unpacker/UnpackerBase.java obtains an attacker-controlled PackFile targetPath, passes it through IoHelper.translatePath(), which only converts separators, and constructs a File without normalizing parent-directory segments or enforcing destination containment. A malicious installer pack entry containing ../ sequences can therefore write outside the intended installation directory to startup folders, executable search paths, or other locations accessible with the victim&amp;#39;s privileges when the victim runs the installer.

*** Pendiente de traducción *** Starlette-Admin is a fast, beautiful and extensible administrative interface framework for FastAPI and Starlette applications. Prior to 0.16.1, the list API does not validate user-supplied order_by and structured where field names against the configured sortable_fields and searchable_fields allowlists. An authenticated user with access to an affected list endpoint can submit arbitrary field names to starlette_admin/base.py and the BaseModelView validation path, bypassing restrictions presented by the administrative user interface. Requests can sort or filter on fields that are not intended to be sortable or searchable, causing limited information exposure. Invalid field names and special Python attribute names such as metadata and the class dunder attribute can also trigger unhandled exceptions and HTTP 500 responses, causing limited denial of service for targeted requests. This issue is fixed in version 0.16.1.

*** Pendiente de traducción *** Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, an unauthenticated HTTP/2 peer can cause an out-of-memory denial of service in the Ember backend with HTTP/2 enabled. The Hpack wrapper in ember-core/shared/src/main/scala/org/http4s/ember/core/h2/Hpack.scala concatenates HEADERS and CONTINUATION frame fragments and decodes them into a single List, but maxHeaderSize accounting does not include indexed headers or HPACK per-header overhead. A small compressed header block can therefore expand into a much larger decoded representation that remains in memory for processing. Servers exposed to untrusted HTTP/2 traffic and clients directed to an untrusted HTTP/2 server are affected, and concurrent malicious connections can exhaust the process heap. This issue is fixed in versions 0.23.35 and 1.0.0-M47.

*** Pendiente de traducción *** Kyverno is a policy engine designed for cloud native platform engineering teams. From 1.18.0 until 1.18.2, the NamespacedMutatingPolicy CEL compiler exposes the generator library to matchConditions, allowing a namespace-scoped policy to invoke generator.apply(namespace, resources) with an arbitrary target namespace. The validation in pkg/cel/policies/mpol/validate.go checks that the policy compiles but does not enforce namespace scope, and GenerateResources in pkg/cel/libs/context.go does not reject the cross-namespace target. A user who can create NamespacedMutatingPolicy objects in one namespace can cause the admission controller, operating with cluster-wide privileges, to create ConfigMaps, NetworkPolicies, Secrets, RoleBindings, and other resources in another namespace, enabling unauthorized modification and potential privilege escalation. This issue is fixed in version 1.18.2.