Base de CVEs

The Piwigo installer in versions 16.3.0 and earlier accepts POST parameters for database configuration and writes them directly into a PHP configuration file without proper sanitization. On PHP 8+, the `addslashes()` protection is bypassed because it checks for `get_magic_quotes_gpc()`, a function removed in PHP 8.0. This allows raw user input to be interpolated directly into PHP source code. An unauthenticated attacker can inject arbitrary PHP code through POST parameters (prefix, dbpasswd, dbhost, dbname, or dbuser), which gets written to `local/config/database.inc.php` and executed on every page load.

In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits Userspace can restore an ITS Device Table Entry whose Size field encodes more EventID bits than the virtual ITS supports. The live MAPD path rejects that state, but vgic_its_restore_dte() accepts it and stores the out-of-range value in dev->num_eventid_bits. Reject restored DTEs with num_eventid_bits > VITS_TYPER_IDBITS before allocating the device. This mirrors the MAPD check and prevents the restored state from reaching vgic_its_restore_itt(), where the unchecked value can be converted into an oversized scan_its_table() range.

In the Linux kernel, the following vulnerability has been resolved: net: tls: prevent chain-after-chain in plain text SG Sashiko points out that if end = 0 (start != 0) the current code will create a chain link to content type right after the wrap link: This would create a chain where the wrap link points directly to another chain link. The scatterlist API sg_next iterator does not recursively resolve consecutive chain links. meaning this is illegal input to crypto. The wrapping link is unnecessary if end = 0. end is the entry after the last one used so end = 0 means there's nothing pushed after the wrap: end start i v v v [ ]...[ ][ d ][ d ][ d ][ d ][rsv for wrap] Skip the wrapping in this case. TLS 1.3 can use the "wrapping slot" for it's chaining if end = 0. This avoids the chain-after-chain. Move the wrap chaining before marking END and chaining off content type, that feels like more logical ordering to me, but should not matter from functional perspective.

No kernel Linux, a seguinte vulnerabilidade foi resolvida: wifi: iwlwifi: mld: corrige explosão de segmentação TSO quando AMSDU está desabilitado Quando a notificação TLC desabilita AMSDU para um TID, o driver MLD define max_tid_amsdu_len com o valor sentinela 1. O caminho de segmentação TSO em iwl_mld_tx_tso_segment() verifica zero, mas não verifica este valor sentinela, permitindo que ele alcance o cálculo de num_subframes: num_subframes = (max_tid_amsdu_len + pad) / (subf_len + pad) = (1 + 2) / (1534 + 2) = 0 Esse zero se propaga para iwl_tx_tso_segment(), que define: gso_size = num_subframes * mss = 0 Chamar skb_gso_segment() com gso_size=0 cria mais de 32000 segmentos minúsculos a partir de um único skb GSO. Isso inunda o anel de TX com cerca de 1024 micro-quadros (o restante é descartado), gerando uma rajada massiva de eventos de conclusão de TX que pode levar a corrupção de memória e a um subsequente use-after-free na fila de retransmissão do TCP (underflow de contador de referência em tcp_shifted_skb, desreferência de NULL em tcp_rack_detect_loss). O driver MVM é imune porque verifica mvmsta->amsdu_enabled antes de chegar ao cálculo de num_subframes. O driver MLD não possui uma verificação equivalente baseada em bitmap e depende somente de max_tid_amsdu_len, que não detecta o valor sentinela. A correção consiste em detectar o valor sentinela (max_tid_amsdu_len == 1) na verificação existente e recorrer à segmentação TSO sem AMSDU. Também é adicionada uma guarda WARN_ON_ONCE após a divisão de num_subframes como defesa em profundidade, para detectar futuros caminhos de código que produzam zero por outro mecanismo.