p PatchFirst

PatchFirst · Vulnérabilités récentes

Vulnérabilités de linux-xilinx-zynqmp · Page n° 83

Vulnérabilités publiées pour linux-xilinx-zynqmp au cours des 30 derniers jours : 589. Présentes dans le catalogue KEV : 0.

Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 8938

  1. CVE-2026-80990

    Faible · CVSS 1EPSS 0,21%Aucun correctif publié

    net: thunderbolt: Release the Rx HopID that was handed out on mismatch

    In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Release the Rx HopID that was handed out on mismatch tb_xdomain_alloc_in_hopid() passes the wanted HopID to ida_alloc_range() as the lower bound, so a taken id is not an error there: the allocator returns the next free one above it. tbnet_connected_work() asks for the peer's transmit path, treats any other id as a failure and returns without releasing what it got, so that allocation stays live for the rest of the XDomain connection with nothing left holding a reference to it. Release the id when it is not the one we asked for, the same way the error unwin

    Publication Mise à jour
  2. CVE-2026-80989

    Élevée · CVSS 8.8EPSS 0,35%Aucun correctif publié

    net: thunderbolt: Mark the connection down when bringing it up fails

    In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Mark the connection down when bringing it up fails Every failure path in tbnet_connected_work() undoes its own work and returns without clearing login_sent, so the connection still looks established. The next tbnet_tear_down() therefore takes its main branch and repeats a teardown that already happened: it stops rings that are already stopped, which is a dev_WARN() and fatal under panic_on_warn, and it releases net->remote_transmit_path even on the HopID mismatch path, where this connection never owned that id, silently freeing one that someone else is sti

    Publication Mise à jour
  3. CVE-2026-80988

    Non évaluéeEPSS 0,18%Aucun correctif publié

    NTB: ntb_transport: Fail TX enqueue when the QP link is down

    In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Fail TX enqueue when the QP link is down Commit f195a1a6fe41 ("ntb: Drop packets when qp link is down") meant to make ntb_transport_tx_enqueue() drop packets submitted while the QP link is down, but it only returns 0 without consuming the packet. Zero means success by this function's contract, so ntb_netdev reports NETDEV_TX_OK and forgets the skb: nothing queued it, nothing frees it, and it leaks, one skb for every transmit racing a link-down. Return -ENOLINK instead, restoring the contract that a non-zero return leaves the buffer owned by the caller.

    Publication Mise à jour
  4. CVE-2026-80987

    Élevée · CVSS 7.5EPSS 0,5%Aucun correctif publié

    NTB: ntb_transport: Reject oversized TX buffers

    In the Linux kernel, the following vulnerability has been resolved: NTB: ntb_transport: Reject oversized TX buffers ntb_process_tx() handles an oversized buffer by calling tx_handler() with a NULL data pointer and returning success. ntb_netdev therefore neither frees the skb in its completion callback nor takes its enqueue error path, leaking it. Reject oversized buffers in ntb_transport_tx_enqueue() before acquiring a queue entry and return -EMSGSIZE. The caller retains ownership of the buffer, and the preceding netdev patch frees the skb when enqueue returns this permanent error.

    Publication Mise à jour
  5. CVE-2026-80983

    Non évaluéeEPSS 0,18%Aucun correctif publié

    net/smc: fix socket refcount leak in smc_switch_conns()

    In the Linux kernel, the following vulnerability has been resolved: net/smc: fix socket refcount leak in smc_switch_conns() smc_switch_conns() takes a reference on the SMC socket before dropping lgr->conns_lock, so the connection stays alive while the CDC slot is fetched: sock_hold(&smc->sk); read_unlock_bh(&lgr->conns_lock); /* pre-fetch buffer outside of send_lock, might sleep */ rc = smc_cdc_get_free_slot(conn, to_lnk, &wr_buf, NULL, &pend); if (rc) goto err_out; The err_out label only drops the wr_tx link reference, so this early exit returns without the matching sock_put(). The

    Publication Mise à jour
  6. CVE-2026-80982

    Élevée · CVSS 7.8EPSS 0,16%Aucun correctif publié

    net/smc: fix use-after-free in smc_rx_pipe_buf_release()

    In the Linux kernel, the following vulnerability has been resolved: net/smc: fix use-after-free in smc_rx_pipe_buf_release() smc_rx_splice() hands RMB pages to a pipe and takes a socket reference per entry so the smc_sock stays alive until the reader finishes. The connection does not: a concurrent close runs smc_conn_free(), which releases the receive buffer back to the link group pool. smc_rx_pipe_buf_release() tests sk_state before taking the socket lock. The state can change between the test and the lock, and smc_rx_update_cons() then dereferences conn->rmb_desc and walks conn->lgr, which smc_conn_free() has already released. On the is_

    Publication Mise à jour
  7. CVE-2026-80980

    Critique · CVSS 9.8EPSS 0,68%Aucun correctif publié

    net/smc: stop killed, freed and out_of_sync sharing a byte

    In the Linux kernel, the following vulnerability has been resolved: net/smc: stop killed, freed and out_of_sync sharing a byte The three connection state flags are single-bit bitfields, so they occupy one byte of struct smc_connection and every store to one is a read-modify-write of the other two: u8 killed : 1; u8 freed : 1; u8 out_of_sync : 1; They are not written under a common lock. smc_cdc_msg_validate() sets out_of_sync from the receive tasklet, while smc_conn_kill() sets killed from process context under lock_sock(), and the receive path does not defer to the backlog when the socket is owned -- smc_cdc_msg_recv() tak

    Publication Mise à jour
  8. CVE-2026-80978

    Élevée · CVSS 7.8EPSS 0,13%Aucun correctif publié

    net: cap advertised IP tunnel headroom

    In the Linux kernel, the following vulnerability has been resolved: net: cap advertised IP tunnel headroom IP tunnel devices derive their advertised needed_headroom from lower output devices. A stack of user-created devices can make the derived value larger than the 16-bit skb header offsets can represent. Once IP output reserves it, skb head expansion can wrap those offsets. The runtime transmit path already caps a growing needed_headroom at 512. Apply the same cap when tunnel configuration publishes needed_headroom derived from a lower output device. Capping the advertised value is safe: IP tunnel transmit still expands the skb when a p

    Publication Mise à jour
  9. CVE-2026-80977

    Élevée · CVSS 7.8EPSS 0,13%Code d’exploitation publicAucun correctif publié

    net: skbuff: don't touch shared zerocopy state in skb_tx_error()

    In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't touch shared zerocopy state in skb_tx_error() skb_tx_error() completes the zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, and skb_zcopy_downgrade_managed() clears SKBFL_MANAGED_FRAG_REFS. Both live in skb_shinfo(), which every clone shares, while the caller only owns the reference it is about to drop. Through a clone it tells the producer its pages are free and drops SKBFL_SHARED_FRAG for an skb that is still in flight. Open vSwitch reaches this with a non-last OVS_ACTION_ATTR_RECIRC: clone_execute() sends a skb_clone() into ovs_dp_process_packet() while d

    Publication Mise à jour
  10. CVE-2026-80976

    Critique · CVSS 9.8EPSS 0,71%Aucun correctif publié

    seg6: reset IP6CB after IPv6 decapsulation

    In the Linux kernel, the following vulnerability has been resolved: seg6: reset IP6CB after IPv6 decapsulation decap_and_validate() pulls the outer SRv6 headers and makes the inner packet the skb network header. The IPv6 control block still contains values collected while parsing the outer packet, including nhoff and extension-header flags. End.DX6 and End.DT6 route the inner IPv6 packet directly to the IPv6 input path. An unprivileged user can reach End.DT6 from a user and net namespace by installing a local SID and injecting an outer packet with Hop-by-Hop and Destination Options headers followed by an SRH and a minimal inner IPv6 packet

    Publication Mise à jour
  11. CVE-2026-80974

    Non évaluéeEPSS 0,21%Aucun correctif publié

    mfd: sm501: Fix potential memory leaks during remove

    In the Linux kernel, the following vulnerability has been resolved: mfd: sm501: Fix potential memory leaks during remove The memory allocated for struct sm501_devdata in sm501_pci_probe() and sm501_plat_probe() is not freed by the corresponding remove functions sm501_pci_remove() and sm501_plat_remove(). Fix that by adding a call to kfree().

    Publication Mise à jour
  12. CVE-2026-80973

    Non évaluéeEPSS 0,22%Aucun correctif publié

    ALSA: 6fire: bound the MIDI event length from the device

    In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: bound the MIDI event length from the device usb6fire_comm_receiver_handler() forwards a MIDI event using a length byte the device supplies, with no bound and no check that the transfer delivered that many bytes: if (!urb->status) { if (rt->receiver_buffer[0] == 0x10) /* midi in event */ if (midi_rt) midi_rt->in_received(midi_rt, rt->receiver_buffer + 2, rt->receiver_buffer[1]); } receiver_buffer is a 64-byte kzalloc() buffer (COMM_RECEIVER_BUFSIZE), so only 62 bytes follow the two-byte header. receiver_buffer[1] is a u8 the device choo

    Publication Mise à jour
  13. CVE-2026-80972

    Non évaluéeEPSS 0,17%Aucun correctif publié

    ALSA: aloop: Check card index validity at probe

    In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Check card index validity at probe aloop driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.

    Publication Mise à jour
  14. CVE-2026-80971

    Élevée · CVSS 7.8EPSS 0,16%Aucun correctif publié

    ALSA: bcd2000: clear the URB pointers on disconnect

    In the Linux kernel, the following vulnerability has been resolved: ALSA: bcd2000: clear the URB pointers on disconnect bcd2000_free_usb_related_resources() frees both URBs and leaves the pointers behind: usb_kill_urb(bcd2k->midi_out_urb); usb_kill_urb(bcd2k->midi_in_urb); usb_free_urb(bcd2k->midi_out_urb); usb_free_urb(bcd2k->midi_in_urb); The rawmidi device outlives that call. A substream that is still open when the device is unplugged reaches bcd2000_midi_send() from the trigger path on close. That function writes to the freed URB and then hands it to the USB core: bcd2k->midi_out_urb->transfer_buffer_length = BUFSIZE; ... r

    Publication Mise à jour
  15. CVE-2026-80969

    Non évaluéeEPSS 0,22%Aucun correctif publié

    ALSA: mpu401: Check card index validity at probe

    In the Linux kernel, the following vulnerability has been resolved: ALSA: mpu401: Check card index validity at probe mpu401 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.

    Publication Mise à jour
  16. CVE-2026-80968

    Non évaluéeEPSS 0,22%Aucun correctif publié

    ALSA: mts64: Check card index validity at probe

    In the Linux kernel, the following vulnerability has been resolved: ALSA: mts64: Check card index validity at probe Although mts64 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as "none" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.

    Publication Mise à jour
  17. CVE-2026-80967

    Élevée · CVSS 8.4EPSS 0,18%Aucun correctif publié

    ALSA: pcxhr: initialize mutexes before requesting threaded IRQ

    In the Linux kernel, the following vulnerability has been resolved: ALSA: pcxhr: initialize mutexes before requesting threaded IRQ pcxhr_probe() requests pcxhr_threaded_irq() before initializing mgr->lock, even though the threaded handler takes that mutex. Initialize the manager locks before request_threaded_irq() so an early interrupt cannot run against uninitialized mutex state during probe.

    Publication Mise à jour
  18. CVE-2026-80966

    Non évaluéeEPSS 0,22%Aucun correctif publié

    ALSA: portman2x4: Check card index validity at probe

    In the Linux kernel, the following vulnerability has been resolved: ALSA: portman2x4: Check card index validity at probe Although portman2x4 driver has a check of the given devptr->id value, it doesn't check for a negative id, which is often given as "none" or such value when bound via sysfs. This may lead to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.

    Publication Mise à jour
  19. CVE-2026-80965

    Non évaluéeEPSS 0,18%Aucun correctif publié

    ALSA: serial-u16550: Check card index validity at probe

    In the Linux kernel, the following vulnerability has been resolved: ALSA: serial-u16550: Check card index validity at probe serial-u16550 driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.

    Publication Mise à jour
  20. CVE-2026-80964

    Non évaluéeEPSS 0,17%Aucun correctif publié

    ALSA: virmidi: Check card index validity at probe

    In the Linux kernel, the following vulnerability has been resolved: ALSA: virmidi: Check card index validity at probe virmidi driver blindly trusts that the given devptr->id value is within the proper card index range at probe. It's OK for the devices the driver itself creates at the module probe time, but if the device is bound manually via sysfs interface, this could be -1 as "none", and this leads to OOB access for index[] and other parameters. Add a sanity check for the card index and warn/correct it if it's a value out of the range.

    Publication Mise à jour

Vérifiez votre serveur

Comparez votre pile et les versions installées aux bases de vulnérabilités actuelles.

Vérifiez votre serveur →