Vulnerabilidades

*** Pendiente de traducción *** A<br /> stack-based buffer overflow vulnerability exists in the firmware update<br /> functionality of TL-MR6400 v7 due to unsafe processing of<br /> attacker-controlled metadata within a firmware image. <br /> <br /> <br /> <br /> <br /> <br /> Successful<br /> exploitation may allow an authenticated attacker to trigger memory corruption<br /> and execute arbitrary code on the affected device.

*** Pendiente de traducción *** A NULL<br /> pointer dereference vulnerability exists in the HTTP request parsing<br /> functionality of <br /> TL-MR6400 v7. An unauthenticated remote attacker can<br /> trigger the vulnerability by sending a specially crafted HTTP request<br /> containing a malformed session cookie header. <br /> <br /> <br /> <br /> <br /> <br /> Successful<br /> exploitation may cause the HTTP service process to crash, resulting in a<br /> denial-of-service condition and temporary loss of management or CGI<br /> functionality until service recovery.

*** Pendiente de traducción *** A<br /> stack-based out-of-bounds write vulnerability exists in the login request<br /> handling functionality of the administrative web interface of TP-Link TL-MR6400 v7 routers. An unauthenticated adjacent attacker can trigger the vulnerability<br /> by sending a specially crafted malformed HTTP request. <br /> <br /> <br /> <br /> <br /> <br /> Successful<br /> exploitation may cause the web service process to crash, resulting in a<br /> denial-of-service condition and temporary loss of access to the router&amp;#39;s web<br /> management interface.

*** Pendiente de traducción *** Cleartext Storage of Sensitive Information in Memory vulnerability in Johnson Controls Simplex Incident Manager / Autocall Fire Administrator may allow an attcker to Retrieve Embedded Sensitive Data.<br /> <br /> This issue affects Simplex Incident Manager / Autocall Fire Administrator: before 2.01.05.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost: reset the vring metadata cache on vring reconfiguration<br /> <br /> vq-&gt;meta_iotlb[] caches the vhost_iotlb_map that backs each vring<br /> metadata region, and iotlb_access_ok() returns early on a cache hit,<br /> taking the hit as proof that the region has already been validated:<br /> <br /> if (vhost_vq_meta_fetch(vq, addr, len, type))<br /> return true;<br /> <br /> The cache is reset on VHOST_IOTLB_UPDATE and VHOST_IOTLB_INVALIDATE, on<br /> device IOTLB (re)initialisation and on vq reset, but not when<br /> VHOST_SET_VRING_ADDR replaces vq-&gt;desc, vq-&gt;avail and vq-&gt;used, nor when<br /> VHOST_SET_VRING_NUM changes the region sizes.<br /> <br /> With a device IOTLB attached both ioctls are accepted while the vq is<br /> live, and neither validates the addresses at ioctl time: vq_access_ok()<br /> and vq_log_used_access_ok() return true early because the addresses are<br /> GIOVAs, deferring validation to prefetch time. Once the cache has been<br /> populated that deferred validation no longer runs -- vq_meta_prefetch()<br /> hits the stale entry and returns true -- and vhost_vq_meta_fetch() keeps<br /> translating through the old mapping as<br /> <br /> map-&gt;addr + addr - map-&gt;start<br /> <br /> for an address the mapping no longer covers. vhost_copy_to_user() and<br /> vhost_copy_from_user() consume the result with __copy_to_user() and<br /> __copy_from_user(), which do not check it either, so a subsequent used<br /> ring update or descriptor fetch accesses memory outside the region the<br /> IOTLB actually maps.<br /> <br /> Reset the metadata cache whenever the vring is reconfigured, so the new<br /> addresses are pushed back through iotlb_access_ok()&amp;#39;s slow path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv6: clear suppressed fib6 rule result<br /> <br /> fib6_rule_suppress() drops a suppressed route with ip6_rt_put_flags(),<br /> but leaves res-&gt;rt6 pointing at the released rt6_info.<br /> <br /> If no later rule supplies a replacement, fib6_rule_lookup() still sees<br /> res.rt6 and returns that stale dst to its caller. A suppressing rule can<br /> therefore leak a released route back to rt6_lookup(), and the next put<br /> hits rcuref_put_slowpath() from dst_release().<br /> <br /> Clear res-&gt;rt6 when suppressing the route so suppressed lookups fall<br /> through to the null dst instead of reusing the released one.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> packet: use consistent hard_header_len in non-ring send paths<br /> <br /> packet_snd() reads dev-&gt;hard_header_len multiple times while allocating<br /> and constructing an skb. Device reconfiguration can change this value<br /> concurrently, for example through bonding device type changes.<br /> <br /> For SOCK_RAW, packet_snd() can save a larger value in reserve and later<br /> allocate headroom using a smaller value. Moving skb-&gt;data back by reserve<br /> then places it before skb-&gt;head, and the following copy from userspace can<br /> attempt an out-of-bounds write.<br /> <br /> packet_sendmsg_spkt() has the same issue because it calculates its<br /> reservation and header offset from separate reads before dropping the RCU<br /> read lock to allocate the skb.<br /> <br /> Add LL_RESERVED_SPACE_EX() for callers that already saved a header length.<br /> Read hard_header_len once in packet_snd() and use it for allocation and<br /> construction. In packet_sendmsg_spkt(), preserve the allocation-time value<br /> through the device lookup retry.<br /> <br /> The separate SOCK_DGRAM consistency problem between hard_header_len and<br /> header_ops-&gt;create is not addressed here.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: cls_route: fix fastmap use-after-free on filter<br /> <br /> The route4 classifier maintains a 16-slot fastmap cache that stores raw<br /> struct route4_filter pointers indexed by (id, iif). The reader<br /> (route4_classify) populates this cache via route4_set_fastmap() for every<br /> classified packet that hits a filter. The writer (route4_delete,<br /> route4_change) clears the cache via route4_reset_fastmap() before<br /> RCU-deferred kfree of the filter.<br /> <br /> This creates a UAF race:<br /> 1. Reader walks the RCU-protected bucket chain, finds filter f<br /> 2. Writer unlinks f, calls route4_reset_fastmap(), then tcf_queue_work()<br /> 3. Reader calls route4_set_fastmap() and writes f into the cache<br /> *after* the writer&amp;#39;s reset, caching a pointer about to be freed<br /> 4. After the RCU grace period, kfree(f) executes<br /> 5. Next classified packet on the same (id, iif) tuple hits the stale<br /> fastmap entry and reads f-&gt;res from freed memory<br /> <br /> Reproduced with an mdelay(100) accelerator in route4_set_fastmap() and a<br /> concurrent add/delete stress test (provided by both zdi and Santosh).<br /> Both triggered KASAN slab-use-after-free reports in the route4 fastmap<br /> paths.<br /> <br /> Fix:<br /> Introduce a per-filter boolean dying flag to suppress stale fastmap<br /> republishing by in-flight readers.