mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steffen Klassert <steffen.klassert@secunet.com>
To: Pedro Falcato <pfalcato@suse.de>
Cc: <cve@kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-cve-announce@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@kernel.org>
Subject: Re: CVE-2026-93105: esp: do not unref managed frag pages in esp_ssg_unref()
Date: Fri, 25 Sep 2026 11:45:37 +0200	[thread overview]
Message-ID: <arZCwVzLNkdLwqIj@secunet.com> (raw)
In-Reply-To: <arY-pm8tfEzTjEI5@pedro-suse.tail5790ac.ts.net>

On Fri, Sep 25, 2026 at 10:30:02AM +0100, Pedro Falcato wrote:
> On Thu, Sep 17, 2026 at 05:16:22PM +0100, Greg Kroah-Hartman wrote:
> > From: Greg Kroah-Hartman <gregkh@kernel.org>
> > 
> > Description
> > ===========
> > 
> > In the Linux kernel, the following vulnerability has been resolved:
> > 
> > esp: do not unref managed frag pages in esp_ssg_unref()
> > 
> > esp_ssg_unref() releases the page references held on the source
> > scatterlist after the AEAD operation completes.  It calls
> > skb_page_unref() on every frag page for an out-of-place transform
> > (req->src != req->dst), and in the error path of esp_output_tail()
> > (already_unref == true) on the request's own scatterlist.
> > 
> > This is wrong when the skb carries managed frags
> > (SKBFL_MANAGED_FRAG_REFS).  Managed frags are owned by a zerocopy ubuf
> > and the skb does not hold a per-frag page reference; io_uring SEND_ZC
> > with a registered buffer attaches the bvec pages this way via
> > io_sg_from_iter().  The rest of the stack honours this invariant:
> > skb_release_data() skips the per-frag unref when SKBFL_MANAGED_FRAG_REFS
> > is set, and skb_zcopy_managed() is the guard used at the other unref
> > sites.
> > 
> > esp_ssg_unref() is missing that guard, so for a managed-frag skb it
> > drops a page reference the skb never acquired.  This can underflow the
> > page reference count and free a page that is still in use.
> > 
> > Guard the function with skb_zcopy_managed() so both unref paths are
> > skipped for managed-frag skbs, matching skb_release_data().
> > 
> > The Linux kernel CVE team has assigned CVE-2026-93105 to this issue.
> > 
> > 
> > Affected and fixed versions
> > ===========================
> > 
> > 	Issue introduced in 4.11 with commit cac2661c53f35cbe651bef9b07026a5a05ab8ce0 and fixed in 7.2.6 with commit 26b6b14c7a0368e317a1e9fb5144ebe6f8d495cf
> > 	Issue introduced in 4.11 with commit cac2661c53f35cbe651bef9b07026a5a05ab8ce0 and fixed in 7.3-rc1 with commit 21697720ff43b8dfa25b8e8d9ca7f56f4597fc80
> > 
> > Please see https://www.kernel.org for a full list of currently supported
> > kernel versions by the kernel community.
> > 
> > Unaffected versions might change over time as fixes are backported to
> > older supported kernel versions.  The official CVE entry at
> > 	https://cve.org/CVERecord/?id=CVE-2026-93105
> > will be updated if fixes are backported, please check that for the most
> > up to date information about this issue.
> > 
> 
> I think this CVE needs to be rejected.
> 
> commit 0fda52de8bbd4ca9a852c8a7ef6536cf82bd71fd
> Author: Steffen Klassert <steffen.klassert@secunet.com>
> Date:   Mon Aug 17 07:17:58 2026 +0200
> 
>     Revert "esp: do not unref managed frag pages in esp_ssg_unref()"
>     
>     This reverts commit 21697720ff43b8dfa25b8e8d9ca7f56f4597fc80.
>     
>     The patch does not fix the issue completely, so revert for
>     now and wait for an updated version.
>     
>     Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>

This is now fixed by:

commit f89416eb3db151170a6f3c6dfc5239d26cdce4d2
Author: Maher Azzouzi <maherazz04@gmail.com>
Date:   Mon Aug 17 14:37:52 2026 +0100

    esp: downgrade zerocopy managed frags before mutating skb frags

    On the out-of-place output path (esp->inplace == false) ESP rewrites the
    skb frag array: esp_output_head() appends a trailer frag and
    esp_output_tail() replaces the frags with a destination page, both
    referenced with get_page().

    When the skb carries zerocopy managed frags (SKBFL_MANAGED_FRAG_REFS) the
    payload frags are owned by the ubuf and must not be referenced or
    unreferenced individually, but ESP mutates the frag array without ever
    downgrading the skb.  This breaks the managed-frag invariant two ways:

      - esp_ssg_unref() walks the source scatterlist and drops a page
        reference for every frag, including the ubuf-owned payload frags,
        pushing their refcount below the GUP pin bias while the pages are
        still pinned, i.e. a use-after-free of the zerocopy pages;

      - esp_output_tail() installs its destination page as frag 0 with
        get_page() but leaves SKBFL_MANAGED_FRAG_REFS set, so
        skb_release_data() takes the skip_unref branch and never drops that
        reference, leaking the x->xfrag page at packet rate.

    Fix this the way every other frag-mutating site does (__ip_append_data(),
    __ip6_append_data(), tcp_sendmsg_locked()) and call
    skb_zcopy_downgrade_managed() before ESP touches the frag array: it takes
    a real reference on each existing frag and clears SKBFL_MANAGED_FRAG_REFS,
    so the per-frag unref in esp_ssg_unref() and the frag release in
    skb_release_data() are both balanced and no mixed-ownership frag array is
    left behind.

    Fixes: 753f1ca4e1e5 ("net: introduce managed frags infrastructure")
    Signed-off-by: Maher Azzouzi <maherazz04@gmail.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>


      reply	other threads:[~2026-09-25  9:45 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2026091746-CVE-2026-93105-78df@gregkh>
2026-09-25  9:30 ` Pedro Falcato
2026-09-25  9:45   ` Steffen Klassert [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=arZCwVzLNkdLwqIj@secunet.com \
    --to=steffen.klassert@secunet.com \
    --cc=cve@kernel.org \
    --cc=gregkh@kernel.org \
    --cc=linux-cve-announce@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pfalcato@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®