CVE Intelligence

Vulnerabilidades do Linux Linux Kernel

🔔 Criar alerta RSS Verificador de versão

CVEs publicadas que afetam Linux Linux Kernel: 4242 registro(s), com versões afetadas e correções.
cpe:2.3:o:linux:linux_kernel

CVE-2026-53242 Alta · 7.8 CWE-476 25/06/2026
ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams
In the Linux kernel, the following vulnerability has been resolved: ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams snd_pcm_drain() uses init_waitqueue_entry which does not clear entry.prev/next, and add_wait_queue with a conditional remove_wait_queue that is skipped when to_check is no longer in the group after concurrent UNLINK. The orphaned wait entry remains on the unlinked substream sleep queue. On the next drain iteration, add_wait_queue adds the entry to a new queue while still linked on the old one, corrupting both lists. A subsequent wake_up dereferences NULL at the func pointer (mapped from the spinlock at offset 0 of the misinterpreted wait_queue_head_t), causing a kernel panic. Replace init_waitqueue_entry/add_wait_queue/conditional remove_wait_queue with init_wait_entry/prepare_to_wait/ finish_wait. init_wait_entry clears prev/next via INIT_LIST_HEAD on each iteration and sets autoremove_wake_function which auto-removes the entry on wake-up. finish_wait safely handles both the already-removed and still-queued cases.
CVE-2026-53241 Média · 5.5 25/06/2026
ALSA: seq: dummy: fix UMP event stack overread
In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: dummy: fix UMP event stack overread The dummy sequencer port forwards events by copying an incoming struct snd_seq_event into a stack temporary, rewriting source and destination, and dispatching the temporary to subscribers. That legacy event storage is smaller than struct snd_seq_ump_event. When a UMP event reaches the dummy client, the copy leaves the UMP flag set but only provides legacy-sized stack storage. The subscriber delivery path then uses snd_seq_event_packet_size() and copies a UMP-sized packet from that stack object, reading past the end of the temporary. Use the existing union __snd_seq_event storage and copy the packet size reported for the incoming event before rewriting the common routing fields. This preserves the full UMP packet for UMP events while keeping legacy event handling unchanged.
CVE-2026-53240 Alta · 8.8 CWE-416 25/06/2026
xfrm: iptfs: fix use-after-free on first_skb in __input_process_payload
In the Linux kernel, the following vulnerability has been resolved: xfrm: iptfs: fix use-after-free on first_skb in __input_process_payload __input_process_payload() stores first_skb into xtfs->ra_newskb under drop_lock when starting partial reassembly, then unlocks and breaks out of the processing loop. The post-loop check reads xtfs->ra_newskb without the lock to decide whether first_skb is still owned: if (first_skb && first_iplen && !defer && first_skb != xtfs->ra_newskb) Between spin_unlock and this read, a concurrent CPU running iptfs_reassem_cont() (or the drop_timer hrtimer) can complete reassembly, NULL xtfs->ra_newskb, and free the skb. The check then evaluates first_skb != NULL as true, and pskb_trim/ip_summed/consume_skb operate on the freed skb — a use-after-free in skbuff_head_cache. Replace the unlocked read with a local bool that records whether first_skb was handed to the reassembly state in the current call. The flag is set after the existing spin_unlock, before the break, using the pointer equality that is stable at that point (first_skb == skb iff first_skb was stored in ra_newskb).
CVE-2026-53239 Alta · 7.8 CWE-416 25/06/2026
xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx()
In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix use-after-free on inexact bin in xfrm_policy_bysel_ctx() Fix the race by pruning the bin while still holding xfrm_policy_lock, before dropping it. Use __xfrm_policy_inexact_prune_bin() directly since the lock is already held. The wrapper xfrm_policy_inexact_prune_bin() becomes unused and is removed. Race: CPU0 (XFRM_MSG_DELPOLICY) CPU1 (XFRM_MSG_NEWSPDINFO) ========================== ========================== xfrm_policy_bysel_ctx(): spin_lock_bh(xfrm_policy_lock) bin = xfrm_policy_inexact_lookup() __xfrm_policy_unlink(pol) spin_unlock_bh(xfrm_policy_lock) xfrm_policy_kill(ret) // wide window, lock not held xfrm_hash_rebuild(): spin_lock_bh(xfrm_policy_lock) __xfrm_policy_inexact_flush(): kfree_rcu(bin) // bin freed spin_unlock_bh(xfrm_policy_lock) xfrm_policy_inexact_prune_bin(bin) // UAF: bin is freed
CVE-2026-53238 Média · 5.5 25/06/2026
netlabel: validate unlabeled address and mask attribute lengths
In the Linux kernel, the following vulnerability has been resolved: netlabel: validate unlabeled address and mask attribute lengths netlbl_unlabel_addrinfo_get() used the address attribute length to determine whether the attribute data could be read as an IPv4 or IPv6 address, but did not independently validate the corresponding mask attribute length. A crafted Generic Netlink request could therefore provide a valid IPv4/IPv6 address attribute with a shorter mask attribute, which would later be read as a full struct in_addr or struct in6_addr. NLA_BINARY policy lengths are maximum lengths by default, so use NLA_POLICY_EXACT_LEN() for the unlabeled IPv4/IPv6 address and mask attributes. This rejects short attributes during policy validation and also exposes the exact length requirements through policy introspection.
CVE-2026-53237 Média · 5.5 CWE-476 25/06/2026
gpio: mvebu: fix NULL pointer dereference in suspend/resume
In the Linux kernel, the following vulnerability has been resolved: gpio: mvebu: fix NULL pointer dereference in suspend/resume mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL. Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select. Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write [00000020] *pgd=00000000 Internal error: Oops: 815 [#1] PREEMPT ARM Modules linked in: CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353 Hardware name: Marvell Armada 370/XP (Device Tree) PC is at regmap_mmio_read+0x38/0x54 LR is at regmap_mmio_read+0x38/0x54 pc : [<c05fd2ac>] lr : [<c05fd2ac>] psr: 200f0013 sp : f0c11d10 ip : 00000000 fp : c100d2f0 r10: c14fb854 r9 : 00000000 r8 : 00000000 r7 : c1799c00 r6 : 00000020 r5 : 00000020 r4 : c179c7c0 r3 : f0a231a0 r2 : 00000020 r1 : 00000020 r0 : 00000000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 135ec059 DAC: 00000051 Call trace: regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac _regmap_bus_reg_read from _regmap_read+0x60/0x154 _regmap_read from regmap_read+0x3c/0x60 regmap_read from mvebu_gpio_suspend+0xa4/0x14c mvebu_gpio_suspend from dpm_run_callback+0x54/0x180 dpm_run_callback from device_suspend+0x124/0x630 device_suspend from dpm_suspend+0x124/0x270 dpm_suspend from dpm_suspend_start+0x64/0x6c dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8 suspend_devices_and_enter from pm_suspend+0x2fc/0x308 pm_suspend from state_store+0x6c/0xc8 state_store from kernfs_fop_write_iter+0x10c/0x1f8 kernfs_fop_write_iter from vfs_write+0x270/0x468 vfs_write from ksys_write+0x70/0xf0 ksys_write from ret_fast_syscall+0x0/0x54 Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.
CVE-2026-53236 Média · 5.5 25/06/2026
tcp: restrict SO_ATTACH_FILTER to priv users
In the Linux kernel, the following vulnerability has been resolved: tcp: restrict SO_ATTACH_FILTER to priv users This patch restricts the use of SO_ATTACH_FILTER (cBPF) on TCP sockets to users with CAP_NET_ADMIN capability. This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.
CVE-2026-53235 Alta · 7.5 25/06/2026
net: add pskb_may_pull() to skb_gro_receive_list()
In the Linux kernel, the following vulnerability has been resolved: net: add pskb_may_pull() to skb_gro_receive_list() skb_gro_receive_list() calls skb_pull(skb, skb_gro_offset(skb)) without first ensuring the data is in the linear area via pskb_may_pull(). When the skb arrives via napi_gro_frags(), skb_headlen can be 0 (all data in page fragments) while skb_gro_offset is non-zero (after IP+TCP header parsing). The skb_pull() then decrements skb->len by skb_gro_offset but skb->data_len stays unchanged, hitting BUG_ON(skb->len < skb->data_len) in __skb_pull(). The UDP fraglist GRO path already contains this guard at udp_offload.c:749. Adding it to skb_gro_receive_list() itself provides centralized protection for all callers (TCP, UDP, and any future protocols), and ensures the precondition of skb_pull() is satisfied before it is called. On pskb_may_pull() failure, set NAPI_GRO_CB(skb)->flush = 1 so the skb is not held as a new GRO head and is instead delivered through the normal receive path, matching the UDP handling.
CVE-2026-53234 Alta · 7.8 CWE-416 25/06/2026
net: ibm: emac: Fix use-after-free during device removal
In the Linux kernel, the following vulnerability has been resolved: net: ibm: emac: Fix use-after-free during device removal The driver was using devm_register_netdev() which causes unregister_netdev() to be deferred until the devres cleanup phase, which runs after emac_remove() returns. This creates a use-after-free window where: 1. emac_remove() is called, which tears down hardware (cancels work, detaches modules, unregisters from MAL) 2. emac_remove() returns 3. devres cleanup runs and finally calls unregister_netdev() During step 3, the network stack might still process packets, triggering emac_irq(), emac_poll(), or other handlers that access now-freed hardware resources (dev->emacp, dev->mal, etc.). Fix this by replacing devm_register_netdev() with manual register_netdev() and calling unregister_netdev() at the beginning of emac_remove(), before any hardware teardown. This ensures the network device is fully stopped and unregistered before hardware resources are released. The change is safe because: - dev->ndev is assigned very early in probe (before any error paths that could bypass emac_remove) - platform_set_drvdata() is only called after successful registration, so emac_remove() only runs for fully registered devices - unregister_netdev() is idempotent and safe to call on any registered device
CVE-2026-53233 Alta · 7.8 CWE-415 25/06/2026
netdev: fix double-free in netdev_nl_bind_rx_doit()
In the Linux kernel, the following vulnerability has been resolved: netdev: fix double-free in netdev_nl_bind_rx_doit() Sashiko flags that genlmsg_reply() always consumes the skb. The error path calls nlmsg_free(rsp) so we can't jump directly to it. Let's not unbind, just propagate the error to the user. This is the typical way of handling genlmsg_reply() failures. They shouldn't happen unless user does something silly like calling the kernel with an already-full rcvbuf.
CVE-2026-53232 Alta · 8.8 25/06/2026
net: phy: clean the sfp upstream if phy probing fails
In the Linux kernel, the following vulnerability has been resolved: net: phy: clean the sfp upstream if phy probing fails Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events. This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.
CVE-2026-53231 Média · 5.5 CWE-667 25/06/2026
net: phy: don't try to setup PHY-driven SFP cages when using genphy
In the Linux kernel, the following vulnerability has been resolved: net: phy: don't try to setup PHY-driven SFP cages when using genphy We don't have support for PHY-driver SFP cages with the genphy code. On top of that, it was found by sashiko that running sfp_bus_add_upstream() for genphy deadlocks, as for genphy the PHY probing runs under RTNL, which isn't the case for non-genphy drivers. This problem was reproduced, and does lead to a deadlock on RTNL. Before the blamed commit, the phy_sfp_probe() call was made by individual PHY drivers, so there was no way to get to the SFP probing path when using genphy. Let's therefore only run phy_sfp_probe when not using genphy.
CVE-2026-53230 Alta · 8.7 CWE-125 25/06/2026
net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer: BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385 CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core] Call Trace: <TASK> dump_stack_lvl+0x69/0xa0 print_report+0x176/0x4e4 kasan_report+0xc8/0x100 mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core] esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core] esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core] esw_vport_change_handler+0x6a/0x90 [mlx5_core] process_one_work+0x87f/0x15e0 worker_thread+0x62b/0x1020 kthread+0x375/0x490 ret_from_fork+0x4dc/0x810 ret_from_fork_asm+0x11/0x20 </TASK> Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.
CVE-2026-53229 Alta · 7.5 CWE-401 25/06/2026
net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.
CVE-2026-53228 Crítica · 9.8 25/06/2026
Kernel Linux, túnel SIT: ponteiro de cabeçalho obsoleto após offload GSO
No kernel Linux, a seguinte vulnerabilidade foi resolvida: ipv6: sit: recarregar o cabeçalho IPv6 interno após os offloads GSO ipip6_tunnel_xmit() armazena em cache o ponteiro para o cabeçalho IPv6 interno no início da função e continua usando esse ponteiro após iptunnel_handle_offloads(). Para skbs GSO, iptunnel_handle_offloads() chama skb_header_unclone(). Quando o cabeçalho do skb está clonado, skb_header_unclone() pode chamar pskb_expand_head(), que pode mover o início (head) do skb. O contrato de pskb_expand_head() exige que os ponteiros para o cabeçalho do skb sejam recarregados após a chamada. Se o ramo posterior skb_realloc_headroom() não for executado, o SIT usa o ponteiro iph6 desatualizado para ler o limite de saltos (hop limit) interno e o campo DS. Isso pode ler a partir de um início de skb já liberado, após o restante do clone do início antigo ser liberado. Recarregar iph6 após o sucesso do auxiliar de offload e antes de leituras subsequentes do cabeçalho IPv6 interno. Manter o recarregamento existente após skb_realloc_headroom(), pois esse ramo também pode substituir o skb.
CVE-2026-53227 Média · 5.5 CWE-401 25/06/2026
net: openvswitch: fix possible kfree_skb of ERR_PTR
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible kfree_skb of ERR_PTR After the patch in the "Fixes" tag, the allocation of the "reply" skb can happen either before or after locking the ovs_mutex. However, error cleanups still follow the classical reversed order, assuming "reply" is allocated before locking: it is freed after unlocking. If "reply" allocation happens after locking the mutex and it fails, "reply" is left with an ERR_PTR, and execution jumps to the correspondent cleanup stage which will try to free an invalid pointer. Fix this by setting the pointer to NULL after having saved its error value.
CVE-2026-53226 Média · 5.5 CWE-401 25/06/2026
gpio: rockchip: fix generic IRQ chip leak on remove
In the Linux kernel, the following vulnerability has been resolved: gpio: rockchip: fix generic IRQ chip leak on remove The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe. However, on driver remove/teardown, the generic chips are not automatically freed when the IRQ domain is removed because the domain flags do not include IRQ_DOMAIN_FLAG_DESTROY_GC. This causes both the domain generic chips structure and the associated generic chips to be leaked. Additionally, the generic chips remain on the global gc_list and may later be visited by generic IRQ chip suspend, resume, or shutdown callbacks after the GPIO bank has been removed, potentially resulting in a use-after-free and kernel crash. Fix the resource leak by explicitly calling irq_domain_remove_generic_chips() before removing the IRQ domain in rockchip_gpio_remove().
CVE-2026-53225 Crítica · 9.1 CWE-908 25/06/2026
Leitura de Memória Não Inicializada em ASCONF do SCTP no Kernel Linux (CVE-2026-53225)
No kernel Linux, o seguinte problema foi resolvido: sctp: corrige uninit-value em __sctp_rcv_asconf_lookup() __sctp_rcv_asconf_lookup() em net/sctp/input.c verifica apenas se o chunk ASCONF comporta o cabeçalho ADDIP e um cabeçalho de parâmetro, e em seguida chama af->from_addr_param(), que lê o endereço completo (16 bytes para IPv6) confiando no comprimento declarado do parâmetro. Um par não autenticado pode enviar um chunk ASCONF final truncado que declara um parâmetro de endereço IPv6, mas termina após o cabeçalho de parâmetro de 4 bytes; alcançado pelo caminho de busca sem associação, from_addr_param() então lê bytes não inicializados após o parâmetro. Impacto: um par SCTP não autenticado faz o caminho de recepção ler até 16 bytes de memória não inicializada além de um parâmetro de endereço ASCONF truncado. O irmão __sctp_rcv_init_lookup() limita os parâmetros com sctp_walk_params(); este caminho implementa a leitura manualmente e omite o limite. Verifique se todo o parâmetro de endereço está dentro do chunk antes que from_addr_param() o leia, na mesma classe de correção do commit 51e5ad549c43 ("net: sctp: fix KMSAN uninit-value in sctp_inq_pop").
CVE-2026-53224 Crítica · 9.1 CWE-125 25/06/2026
Leitura fora dos limites no SCTP do kernel Linux por validação insuficiente do chunk INIT e da lista de endereços em COOKIE_ECHO
No kernel Linux, a seguinte vulnerabilidade foi resolvida: sctp: validar comprimentos do chunk INIT incorporado e da lista de endereços no cookie sctp_unpack_cookie() verificava apenas se o comprimento do chunk INIT incorporado não excedia o restante do payload do cookie, mas não garantia que o chunk INIT fosse grande o suficiente para conter um cabeçalho INIT completo. Um COOKIE_ECHO malformado pode, portanto, carregar um chunk INIT truncado cujo campo de comprimento é menor que sizeof(struct sctp_init_chunk). Posteriormente, sctp_process_init() acessa parâmetros INIT incondicionalmente, o que pode levar a leituras fora dos limites. Além disso, raw_addr_list_len não é totalmente validado em relação ao restante do payload do cookie. Quando a autenticação de cookie está desabilitada, um atacante pode fornecer um raw_addr_list_len superdimensionado e fazer com que sctp_raw_to_bind_addrs() leia além do fim do cookie. O analisador de endereços também carece de verificações de limites suficientes para cabeçalhos e comprimentos de parâmetros, permitindo que parâmetros de endereço malformados desencadeiem leituras fora dos limites. Para corrigir isso: - exigindo que o comprimento do chunk INIT incorporado seja pelo menos sizeof(struct sctp_init_chunk); - validando que o chunk INIT e a lista de endereços brutos caibam juntos dentro do payload do cookie; - verificando que existam dados suficientes para cada cabeçalho e payload de parâmetro de endereço antes de analisá-lo. Observe que sctp_verify_init() deve ser chamado após sctp_unpack_cookie() e antes de sctp_process_init() quando a autenticação de cookie estiver desabilitada. Isso será tratado em um patch separado.
CVE-2026-53223 Alta · 7.1 25/06/2026
net: guard timestamp cmsgs to real error queue skbs
In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.
CVE-2026-53222 Média · 5.5 CWE-401 25/06/2026
ptp: ocp: fix resource freeing order
In the Linux kernel, the following vulnerability has been resolved: ptp: ocp: fix resource freeing order Commit a60fc3294a37 ("ptp: rework ptp_clock_unregister() to disable events") added a call to ptp_disable_all_events() which changes the configuration of pins if they support EXTTS events. In ptp_ocp_detach() pins resources are freed before ptp_clock_unregister() and it leads to use-after-free during driver removal. Fix it by changing the order of free/unregister calls. To avoid irq handler running on the other core while ptp device unregistering, call synchronize_irq() after HW is configured to stop producing irqs and no irqs are in-flight.
CVE-2026-53221 Crítica · 9.8 25/06/2026
Falha de correspondência de túnel no ip6_vti do kernel Linux (CVE-2026-53221)
No kernel Linux, a seguinte vulnerabilidade foi resolvida: ip6_vti: corrige correspondência incorreta de túnel em vti6_tnl_lookup() Em vti6_tnl_lookup(), quando uma correspondência exata para um túnel falha, a função recorre à busca por túneis curinga: - Túneis que correspondem ao endereço local do pacote, com qualquer endereço remoto curinga remoto). - Túneis que correspondem ao endereço remoto do pacote, com qualquer endereço local (curinga local). No entanto, o vti6 armazena todos esses diferentes tipos de túneis na mesma tabela hash (ip6n->tnls_r_l), sujeita a colisões de hash. O bug é que os laços de busca de fallback em vti6_tnl_lookup() não tinham verificações para garantir que o túnel candidato realmente tenha um endereço curinga.
CVE-2026-53220 Média · 5.5 CWE-476 25/06/2026
netfilter: revalidate bridge ports
In the Linux kernel, the following vulnerability has been resolved: netfilter: revalidate bridge ports ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject. A mere NULL check isn't sufficient, however. As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan. If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path. Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact: Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off. Fixes tag is a common ancestor, this was always broken.
CVE-2026-53219 Média · 5.5 25/06/2026
netfilter: x_tables: avoid leaking percpu counter pointers
In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: avoid leaking percpu counter pointers The native and compat get-entries paths copy the fixed rule entry header from the kernelized rule blob to userspace before overwriting the entry's counter fields with a sanitized counter snapshot. On SMP kernels, entry->counters.pcnt contains the percpu allocation address used by x_tables rule counters. A caller can provide a userspace buffer that faults during the initial fixed-header copy after pcnt has been copied but before the later sanitized counter copy runs. The syscall then returns -EFAULT while leaving the raw percpu pointer in userspace. Copy only the fixed entry prefix before counters from the kernelized rule blob, then copy the sanitized counter snapshot into the counter field. Apply this ordering to the IPv4, IPv6, and ARP native and compat get-entries implementations so a fault cannot expose the internal percpu counter pointer.
CVE-2026-53218 Média · 5.5 CWE-908 25/06/2026
netfilter: nft_exthdr: fix register tracking for F_PRESENT flag
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_exthdr: fix register tracking for F_PRESENT flag nft_exthdr_init() passes user-controlled priv->len to nft_parse_register_store(), which marks that many bytes in the register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT is set, the eval paths write only 1 byte (nft_reg_store8) or 4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nft_regs. Bail out if userspace requests too much data when F_PRESENT is set.