{"id":"CVE-2026-99079","kind":"vulnerability","aliases":["CVE-2026-99079"],"related":[],"title":"Linux kernel: mlx5 XSK refill retry can publish the same buffer twice","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Prevent stale XSK buffer release on refill retry\n\nWhen an XDP redirect to an AF_XDP socket fails because its RX ring is\nfull, the XSK core frees the buffer. During the subsequent batched refill\nof a legacy cyclic RQ, mlx5e also releases the WQE's XSK buffer before\nallocating a replacement. If that refill succeeds only partially, a WQE\nleft without a replacement retains its old buffer pointer.\n\nThe buffer can meanwhile be allocated to another WQE. A later refill\nretry can then free the live buffer through the stale pointer and publish\nthe same UMEM frame twice.\n\nMark the WQE as released immediately after the driver-side free. The flag\nis already cleared when a replacement buffer is assigned, so refill\nretries no longer release stale pointers.\n\nThe failure is silent and produces no kernel warning or splat. A\nstandalone legacy cyclic-RQ zero-copy libxsk reproducer, using 64-byte UDP\ntraffic offered at 12 Mpps, detected it: stock stopped after 2,854,914\npackets in 4.094 seconds, with 4,542 xdp_rx_ring_full events and 64\nownership/double-publication errors. With this change it processed\n356,904,225 packets in 30 seconds despite 571,405 xdp_rx_ring_full events,\nwith no ownership or data errors.","summary":"In the Linux mlx5e driver, a partially failed refill of an AF_XDP receive ring can leave a stale buffer pointer that is freed again on retry. The sources report that this causes the same UMEM frame to be published twice, which can corrupt packet data.","severity":"unknown","cvss":null,"epss":null,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["afxdp","bare-metal","infrastructure","linux-kernel","mlx5","xdp"],"not_affected_if":["no-afxdp-zero-copy","no-mlx5-nic"],"how_to_check":"- unknown","fix":"- unknown","status":"open","published_at":"2026-10-23T13:17:32+00:00","first_seen_at":"2026-10-23T21:57:34+00:00","triaged_at":"2026-10-25T04:53:39+00:00","updated_at":"2026-10-25T04:53:39+00:00","category":"infrastructure","confidence":0.5,"triage":{"at":"2026-10-25T04:53:39Z","model":"claude-haiku-5-5","output":{"fix":"- unknown","reach":"network","title":"Linux kernel: mlx5 XSK refill retry can publish the same buffer twice","impact":"medium","summary":"In the Linux mlx5e driver, a partially failed refill of an AF_XDP receive ring can leave a stale buffer pointer that is freed again on retry. The sources report that this causes the same UMEM frame to be published twice, which can corrupt packet data.","category":"infrastructure","nicknames":[],"who_cares":["linux-kernel","mlx5","afxdp","xdp","bare-metal"],"confidence":0.5,"needs_auth":"no","worst_case":"unknown; sources report buffer double-publication and ownership errors, not code execution","analyst_note":"Check the kernel commit and affected version ranges at the NVD entry and the kernel stable tree; the sources give no fixed version or exploitability detail.","how_to_check":"- unknown","needs_analyst":true,"not_affected_if":["no-mlx5-nic","no-afxdp-zero-copy"],"who_is_affected":"Hosts running a Linux kernel with the mlx5e driver (Mellanox/NVIDIA ConnectX NICs) that use AF_XDP zero-copy sockets with legacy cyclic receive queues are the ones the report describes. Systems without mlx5 NICs or without AF_XDP zero-copy receive are not described as affected. The sources do not state which kernel versions carry the flaw.","user_interaction":"no","needs_special_setup":"yes","severity_if_unknown":"unknown"},"cost_usd":0.00064,"input_tokens":3702,"output_tokens":540,"severity_before":"unknown"},"analyst_status":null,"analyst_note":null,"search":"'-2026':14A,17A '-99079':15A,18A '12':245C '2':252C '225':278C '30':281C '356':276C '4':260C '4.094':257C '405':285C '542':261C '571':284C '64':239C,268C '854':253C '904':277C '914':254C 'af':40B,100C 'afxdp':19B 'alloc':135C,160C 'alreadi':200C 'also':127C 'anoth':162C 'assign':207C 'bare':21B 'bare-met':20B 'batch':119C 'buffer':11A,48B,89C,115C,133C,153C,156C,173C,205C 'byte':240C 'caus':61B 'chang':273C 'clear':201C 'copi':235C 'core':112C 'corrupt':72B 'cve':13A,16A 'cyclic':124C,231C 'cyclic-rq':230C 'data':74B,295C 'despit':283C 'detect':247C 'driver':33B,194C 'driver-sid':193C 'error':270C,296C 'event':266C,290C 'fail':36B,103C 'failur':217C 'flag':198C 'follow':80C 'frame':65B,183C 'free':113C,170C,196C 'freed':52B 'full':109C,265C,289C 'immedi':190C 'infrastructur':23B 'kernel':2A,26B,78C,223C 'later':165C 'leav':45B 'left':146C 'legaci':123C,229C 'libxsk':236C 'linux':1A,25B,31B,77C 'linux-kernel':24B 'live':172C 'longer':212C 'mark':185C 'meanwhil':158C 'metal':22B 'mlx5':3A,27B 'mlx5e':32B,126C 'mpps':246C 'net/mlx5e':85C 'offer':243C 'old':152C 'ownership':293C 'ownership/double-publication':269C 'packet':73B,255C,279C 'partial':35B,143C 'pointer':49B,154C,177C,215C 'prevent':86C 'process':275C 'produc':221C 'publish':8A,68B,179C 'receiv':42B 'redirect':97C 'refil':5A,37B,92C,120C,140C,166C,209C 'releas':90C,128C,189C,213C 'replac':137C,149C,204C 'report':58B 'reproduc':237C 'resolv':84C 'retain':150C 'retri':6A,55B,93C,167C,210C 'ring':43B,107C,264C,288C 'rq':125C,232C 'rx':106C,263C,287C 'second':258C,282C 'side':195C 'silent':219C 'socket':102C 'sourc':57B 'splat':226C 'stale':47B,87C,176C,214C 'standalon':228C 'stock':249C 'stop':250C 'subsequ':118C 'succeed':141C 'traffic':242C 'twice':12A,69B,184C 'udp':241C 'umem':64B,182C 'use':238C 'vulner':81C 'warn':224C 'without':147C 'wqe':130C,145C,163C,187C 'xdp':28B,41B,96C,101C,262C,286C 'xsk':4A,88C,111C,132C 'zero':234C 'zero-copi':233C","nicknames":[],"mitigations":[],"who_affected":"Hosts running a Linux kernel with the mlx5e driver (Mellanox/NVIDIA ConnectX NICs) that use AF_XDP zero-copy sockets with legacy cyclic receive queues are the ones the report describes. Systems without mlx5 NICs or without AF_XDP zero-copy receive are not described as affected. The sources do not state which kernel versions carry the flaw.","tier":"C","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-23T13:17:32+00:00","kev":null,"cvss_vector":null,"cvss_by":null,"poc_count":0,"sources":[{"source":"nvd","external_id":"CVE-2026-99079","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-99079","severity":null,"published_at":"2026-10-23T13:17:32+00:00","modified_at":"2026-10-23T13:17:32+00:00","first_seen_at":"2026-10-23T21:57:34+00:00","fetched_at":"2026-10-23T22:29:03+00:00","note":null}],"documents":[],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}