Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: properly keep track of conduit reference<br /> <br /> Problem description<br /> -------------------<br /> <br /> DSA has a mumbo-jumbo of reference handling of the conduit net device<br /> and its kobject which, sadly, is just wrong and doesn&amp;#39;t make sense.<br /> <br /> There are two distinct problems.<br /> <br /> 1. The OF path, which uses of_find_net_device_by_node(), never releases<br /> the elevated refcount on the conduit&amp;#39;s kobject. Nominally, the OF and<br /> non-OF paths should result in objects having identical reference<br /> counts taken, and it is already suspicious that<br /> dsa_dev_to_net_device() has a put_device() call which is missing in<br /> dsa_port_parse_of(), but we can actually even verify that an issue<br /> exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command<br /> "before" and "after" applying this patch:<br /> <br /> (unbind the conduit driver for net device eno2)<br /> echo 0000:00:00.2 &gt; /sys/bus/pci/drivers/fsl_enetc/unbind<br /> <br /> we see these lines in the output diff which appear only with the patch<br /> applied:<br /> <br /> kobject: &amp;#39;eno2&amp;#39; (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)<br /> kobject: &amp;#39;109&amp;#39; (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)<br /> <br /> 2. After we find the conduit interface one way (OF) or another (non-OF),<br /> it can get unregistered at any time, and DSA remains with a long-lived,<br /> but in this case stale, cpu_dp-&gt;conduit pointer. Holding the net<br /> device&amp;#39;s underlying kobject isn&amp;#39;t actually of much help, it just<br /> prevents it from being freed (but we never need that kobject<br /> directly). What helps us to prevent the net device from being<br /> unregistered is the parallel netdev reference mechanism (dev_hold()<br /> and dev_put()).<br /> <br /> Actually we actually use that netdev tracker mechanism implicitly on<br /> user ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces with<br /> the DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link().<br /> But time still passes at DSA switch probe time between the initial<br /> of_find_net_device_by_node() code and the user port creation time, time<br /> during which the conduit could unregister itself and DSA wouldn&amp;#39;t know<br /> about it.<br /> <br /> So we have to run of_find_net_device_by_node() under rtnl_lock() to<br /> prevent that from happening, and release the lock only with the netdev<br /> tracker having acquired the reference.<br /> <br /> Do we need to keep the reference until dsa_unregister_switch() /<br /> dsa_switch_shutdown()?<br /> 1: Maybe yes. A switch device will still be registered even if all user<br /> ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not<br /> make user port errors fatal"), and the cpu_dp-&gt;conduit pointers<br /> remain valid. I haven&amp;#39;t audited all call paths to see whether they<br /> will actually use the conduit in lack of any user port, but if they<br /> do, it seems safer to not rely on user ports for that reference.<br /> 2. Definitely yes. We support changing the conduit which a user port is<br /> associated to, and we can get into a situation where we&amp;#39;ve moved all<br /> user ports away from a conduit, thus no longer hold any reference to<br /> it via the net device tracker. But we shouldn&amp;#39;t let it go nonetheless<br /> - see the next change in relation to dsa_tree_find_first_conduit()<br /> and LAG conduits which disappear.<br /> We have to be prepared to return to the physical conduit, so the CPU<br /> port must explicitly keep another reference to it. This is also to<br /> say: the user ports and their CPU ports may not always keep a<br /> reference to the same conduit net device, and both are needed.<br /> <br /> As for the conduit&amp;#39;s kobject for the /sys/class/net/ entry, we don&amp;#39;t<br /> care about it, we can release it as soon as we hold the net device<br /> object itself.<br /> <br /> History and blame attribution<br /> -----------------------------<br /> <br /> The code has been refactored so many times, it is very difficult to<br /> follow and properly attribute a blame, but I&amp;#39;ll try to make a short<br /> history which I hope to be correct.<br /> <br /> We have two distinct probing paths:<br /> - one for OF, introduced in 2016 i<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: Fix memory leak in get_file_all_info()<br /> <br /> In get_file_all_info(), if vfs_getattr() fails, the function returns<br /> immediately without freeing the allocated filename, leading to a memory<br /> leak.<br /> <br /> Fix this by freeing the filename before returning in this error case.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: rtl8150: fix memory leak on usb_submit_urb() failure<br /> <br /> In async_set_registers(), when usb_submit_urb() fails, the allocated<br /> async_req structure and URB are not freed, causing a memory leak.<br /> <br /> The completion callback async_set_reg_cb() is responsible for freeing<br /> these allocations, but it is only called after the URB is successfully<br /> submitted and completes (successfully or with error). If submission<br /> fails, the callback never runs and the memory is leaked.<br /> <br /> Fix this by freeing both the URB and the request structure in the error<br /> path when usb_submit_urb() fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: s390: Fix gmap_helper_zap_one_page() again<br /> <br /> A few checks were missing in gmap_helper_zap_one_page(), which can lead<br /> to memory corruption in the guest under specific circumstances.<br /> <br /> Add the missing checks.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: defer interrupt enabling until NAPI registration<br /> <br /> Currently, interrupts are automatically enabled immediately upon<br /> request. This allows interrupt to fire before the associated NAPI<br /> context is fully initialized and cause failures like below:<br /> <br /> [ 0.946369] Call Trace:<br /> [ 0.946369] <br /> [ 0.946369] __napi_poll+0x2a/0x1e0<br /> [ 0.946369] net_rx_action+0x2f9/0x3f0<br /> [ 0.946369] handle_softirqs+0xd6/0x2c0<br /> [ 0.946369] ? handle_edge_irq+0xc1/0x1b0<br /> [ 0.946369] __irq_exit_rcu+0xc3/0xe0<br /> [ 0.946369] common_interrupt+0x81/0xa0<br /> [ 0.946369] <br /> [ 0.946369] <br /> [ 0.946369] asm_common_interrupt+0x22/0x40<br /> [ 0.946369] RIP: 0010:pv_native_safe_halt+0xb/0x10<br /> <br /> Use the `IRQF_NO_AUTOEN` flag when requesting interrupts to prevent auto<br /> enablement and explicitly enable the interrupt in NAPI initialization<br /> path (and disable it during NAPI teardown).<br /> <br /> This ensures that interrupt lifecycle is strictly coupled with<br /> readiness of NAPI context.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/core: always drop device refcount in ib_del_sub_device_and_put()<br /> <br /> Since nldev_deldev() (introduced by commit 060c642b2ab8 ("RDMA/nldev: Add<br /> support to add/delete a sub IB device through netlink") grabs a reference<br /> using ib_device_get_by_index() before calling ib_del_sub_device_and_put(),<br /> we need to drop that reference before returning -EOPNOTSUPP error.

*** Pendiente de traducción *** A denial-of-service (DoS) vulnerability exists in google.protobuf.json_format.ParseDict() in Python, where the max_recursion_depth limit can be bypassed when parsing nested google.protobuf.Any messages.<br /> <br /> Due to missing recursion depth accounting inside the internal Any-handling logic, an attacker can supply deeply nested Any structures that bypass the intended recursion limit, eventually exhausting Python’s recursion stack and causing a RecursionError.

*** Pendiente de traducción *** An unauthenticated information disclosure vulnerability exists in Newgen OmniDocs due to missing authentication and access control on the /omnidocs/GetListofCabinet API endpoint. A remote attacker can access this endpoint without valid credentials to retrieve sensitive internal configuration information, including cabinet names and database-related metadata. This allows unauthorized enumeration of backend deployment details and may facilitate further targeted attacks.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conncount: fix leaked ct in error paths<br /> <br /> There are some situations where ct might be leaked as error paths are<br /> skipping the refcounted check and return immediately. In order to solve<br /> it make sure that the check is always called.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KEYS: trusted: Fix a memory leak in tpm2_load_cmd<br /> <br /> &amp;#39;tpm2_load_cmd&amp;#39; allocates a tempoary blob indirectly via &amp;#39;tpm2_key_decode&amp;#39;<br /> but it is not freed in the failure paths. Address this by wrapping the blob<br /> into with a cleanup helper.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/handshake: restore destructor on submit failure<br /> <br /> handshake_req_submit() replaces sk-&gt;sk_destruct but never restores it when<br /> submission fails before the request is hashed. handshake_sk_destruct() then<br /> returns early and the original destructor never runs, leaking the socket.<br /> Restore sk_destruct on the error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/poll: correctly handle io_poll_add() return value on update<br /> <br /> When the core of io_uring was updated to handle completions<br /> consistently and with fixed return codes, the POLL_REMOVE opcode<br /> with updates got slightly broken. If a POLL_ADD is pending and<br /> then POLL_REMOVE is used to update the events of that request, if that<br /> update causes the POLL_ADD to now trigger, then that completion is lost<br /> and a CQE is never posted.<br /> <br /> Additionally, ensure that if an update does cause an existing POLL_ADD<br /> to complete, that the completion value isn&amp;#39;t always overwritten with<br /> -ECANCELED. For that case, whatever io_poll_add() set the value to<br /> should just be retained.