Vulnerabilities

Incomplete validation of AI rich response messages for Instagram Reels in WhatsApp for iOS v2.25.8.0 to v2.26.15.72 and WhatsApp for Android v2.25.8.0 to v2.26.7.10 could have allowed a user to trigger processing of media content from an arbitrary URL on another user’s device, including triggering OS-controlled custom URL scheme handlers. We have not seen evidence of exploitation in the wild.

A flaw has been found in Open5GS up to 2.7.7. This issue affects the function bsf_sess_find_by_ipv6prefix of the file /src/bsf/context.c of the component BSF. This manipulation of the argument ipv6Prefix causes denial of service. It is possible to initiate the attack remotely. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet.

An issue was discovered in Prosody before 0.12.6 and 1.0.0 through 13.0.0 before 13.0.5. A Denial of Service can occur via memory exhaustion caused by XML parsing resource amplification from unauthenticated connections.

An issue was discovered in Prosody before 0.12.6 and 1.0.0 through 13.0.0 before 13.0.5. A Denial of Service can occur via memory exhaustion caused by memory leaks from unauthenticated connections.

An issue was discovered in Prosody before 0.12.6 and 1.0.0 through 13.0.0 before 13.0.5, when mod_proxy65 is enabled. Because mod_proxy65 mishandles access control in a paused scenario, relaying of unauthenticated traffic can occur.

An issue was discovered in Prosody before 0.12.6 and 1.0.0 through 13.0.0 before 13.0.5, when mod_proxy65 is enabled. Because mod_proxy65 mishandles access control in the activation scenario, relaying of unauthenticated traffic can occur.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: correctly handle tunneled traffic on IPV6_CSUM GSO fallback<br /> <br /> NETIF_F_IPV6_CSUM only advertises support for checksum offload of<br /> packets without IPv6 extension headers. Packets with extension<br /> headers must fall back onto software checksumming. Since TSO<br /> depends on checksum offload, those must revert to GSO.<br /> <br /> The below commit introduces that fallback. It always checks<br /> network header length. For tunneled packets, the inner header length<br /> must be checked instead. Extend the check accordingly.<br /> <br /> A special case is tunneled packets without inner IP protocol. Such as<br /> RFC 6951 SCTP in UDP. Those are not standard IPv6 followed by<br /> transport header either, so also must revert to the software GSO path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: file: Use kzalloc_flex for aio_cmd<br /> <br /> The target_core_file doesn&amp;#39;t initialize the aio_cmd-&gt;iocb for the<br /> ki_write_stream. When a write command fd_execute_rw_aio() is executed,<br /> we may get a bogus ki_write_stream value, causing unintended write<br /> failure status when checking iocb-&gt;ki_write_stream &gt; max_write_streams<br /> in the block device.<br /> <br /> Let&amp;#39;s just use kzalloc_flex when allocating the aio_cmd and let<br /> ki_write_stream=0 to fix this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: fix use-after-free in add_adev() error path<br /> <br /> If auxiliary_device_add() fails, add_adev() jumps to add_fail and calls<br /> auxiliary_device_uninit(adev).<br /> <br /> The auxiliary device has its release callback set to adev_release(),<br /> which frees the containing struct mana_adev. Since adev is embedded in<br /> struct mana_adev, the subsequent fall-through to init_fail and access<br /> to adev-&gt;id may result in a use-after-free.<br /> <br /> Fix this by saving the allocated auxiliary device id in a local<br /> variable before calling auxiliary_device_add(), and use that saved id<br /> in the cleanup path after auxiliary_device_uninit().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: wacom: fix out-of-bounds read in wacom_intuos_bt_irq<br /> <br /> The wacom_intuos_bt_irq() function processes Bluetooth HID reports<br /> without sufficient bounds checking. A maliciously crafted short report<br /> can trigger an out-of-bounds read when copying data into the wacom<br /> structure.<br /> <br /> Specifically, report 0x03 requires at least 22 bytes to safely read<br /> the processed data and battery status, while report 0x04 (which<br /> falls through to 0x03) requires 32 bytes.<br /> <br /> Add explicit length checks for these report IDs and log a warning if<br /> a short report is received.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: check tdls flag in ieee80211_tdls_oper<br /> <br /> When NL80211_TDLS_ENABLE_LINK is called, the code only checks if the<br /> station exists but not whether it is actually a TDLS station. This<br /> allows the operation to proceed for non-TDLS stations, causing<br /> unintended side effects like modifying channel context and HT<br /> protection before failing.<br /> <br /> Add a check for sta-&gt;sta.tdls early in the ENABLE_LINK case, before<br /> any side effects occur, to ensure the operation is only allowed for<br /> actual TDLS peers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: lec: fix use-after-free in sock_def_readable()<br /> <br /> A race condition exists between lec_atm_close() setting priv-&gt;lecd<br /> to NULL and concurrent access to priv-&gt;lecd in send_to_lecd(),<br /> lec_handle_bridge(), and lec_atm_send(). When the socket is freed<br /> via RCU while another thread is still using it, a use-after-free<br /> occurs in sock_def_readable() when accessing the socket&amp;#39;s wait queue.<br /> <br /> The root cause is that lec_atm_close() clears priv-&gt;lecd without<br /> any synchronization, while callers dereference priv-&gt;lecd without<br /> any protection against concurrent teardown.<br /> <br /> Fix this by converting priv-&gt;lecd to an RCU-protected pointer:<br /> - Mark priv-&gt;lecd as __rcu in lec.h<br /> - Use rcu_assign_pointer() in lec_atm_close() and lecd_attach()<br /> for safe pointer assignment<br /> - Use rcu_access_pointer() for NULL checks that do not dereference<br /> the pointer in lec_start_xmit(), lec_push(), send_to_lecd() and<br /> lecd_attach()<br /> - Use rcu_read_lock/rcu_dereference/rcu_read_unlock in send_to_lecd(),<br /> lec_handle_bridge() and lec_atm_send() to safely access lecd<br /> - Use rcu_assign_pointer() followed by synchronize_rcu() in<br /> lec_atm_close() to ensure all readers have completed before<br /> proceeding. This is safe since lec_atm_close() is called from<br /> vcc_release() which holds lock_sock(), a sleeping lock.<br /> - Remove the manual sk_receive_queue drain from lec_atm_close()<br /> since vcc_destroy_socket() already drains it after lec_atm_close()<br /> returns.<br /> <br /> v2: Switch from spinlock + sock_hold/put approach to RCU to properly<br /> fix the race. The v1 spinlock approach had two issues pointed out<br /> by Eric Dumazet:<br /> 1. priv-&gt;lecd was still accessed directly after releasing the<br /> lock instead of using a local copy.<br /> 2. The spinlock did not prevent packets being queued after<br /> lec_atm_close() drains sk_receive_queue since timer and<br /> workqueue paths bypass netif_stop_queue().<br /> <br /> Note: Syzbot patch testing was attempted but the test VM terminated<br /> unexpectedly with "Connection to localhost closed by remote host",<br /> likely due to a QEMU AHCI emulation issue unrelated to this fix.<br /> Compile testing with "make W=1 net/atm/lec.o" passes cleanly.