All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Christian Hopps <chopps@chopps.org>
Cc: devel@linux-ipsec.org,
	Steffen Klassert <steffen.klassert@secunet.com>,
	netdev@vger.kernel.org, Christian Hopps <chopps@labn.net>
Subject: Re: [PATCH ipsec-next v7 07/16] xfrm: iptfs: add new iptfs xfrm mode impl
Date: Thu, 1 Aug 2024 14:13:10 +0200	[thread overview]
Message-ID: <20240801121310.GA10274@breakpoint.cc> (raw)
In-Reply-To: <20240801080314.169715-8-chopps@chopps.org>

Christian Hopps <chopps@chopps.org> wrote:
> +static int __iptfs_init_state(struct xfrm_state *x,
> +			      struct xfrm_iptfs_data *xtfs)
> +{
> +	/* Modify type (esp) adjustment values */
> +
> +	if (x->props.family == AF_INET)
> +		x->props.header_len += sizeof(struct iphdr) + sizeof(struct ip_iptfs_hdr);
> +	else if (x->props.family == AF_INET6)
> +		x->props.header_len += sizeof(struct ipv6hdr) + sizeof(struct ip_iptfs_hdr);
> +	x->props.enc_hdr_len = sizeof(struct ip_iptfs_hdr);
> +
> +	/* Always have a module reference if x->mode_data is set */
> +	if (!try_module_get(x->mode_cbs->owner))
> +		return -EINVAL;

If the comment means that we already have a module owner ref taken
before this try_module_get, then this should use __module_get and
a mention where the first ref was taken.

If not, then this needs an explanation as to what prevents another cpu to
rmmod the owning module between the lookup in xfrm_init_state and the
module reference in __iptfs_init_state.

cpu0					cpu1
 xfrm_init_state
   -> xfrm_get_mode_cbs                 rmmod
     -> __iptfs_init_state		  xfrm_iptfs_fini
       <interrupt>                         xfrm_unregister_mode_cbs
                                            release memory
       <resume>
	try_module_get -> UaF

  reply	other threads:[~2024-08-01 12:13 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-01  8:02 [PATCH ipsec-next v7 00/16] Add IP-TFS mode to xfrm Christian Hopps
2024-08-01  8:02 ` [PATCH ipsec-next v7 01/16] xfrm: config: add CONFIG_XFRM_IPTFS Christian Hopps
2024-08-01  8:03 ` [PATCH ipsec-next v7 02/16] include: uapi: add ip_tfs_*_hdr packet formats Christian Hopps
2024-08-01  8:03 ` [PATCH ipsec-next v7 03/16] include: uapi: add IPPROTO_AGGFRAG for AGGFRAG in ESP Christian Hopps
2024-08-01  8:03 ` [PATCH ipsec-next v7 04/16] xfrm: netlink: add config (netlink) options Christian Hopps
2024-08-01  8:03 ` [PATCH ipsec-next v7 05/16] xfrm: add mode_cbs module functionality Christian Hopps
2024-08-01  8:03 ` [PATCH ipsec-next v7 06/16] xfrm: add generic iptfs defines and functionality Christian Hopps
2024-08-01  8:03 ` [PATCH ipsec-next v7 07/16] xfrm: iptfs: add new iptfs xfrm mode impl Christian Hopps
2024-08-01 12:13   ` Florian Westphal [this message]
2024-08-01 12:36     ` Christian Hopps
2024-08-01 13:09       ` Florian Westphal
2024-08-01  8:03 ` [PATCH ipsec-next v7 08/16] xfrm: iptfs: add user packet (tunnel ingress) handling Christian Hopps
2024-08-01 12:18   ` Florian Westphal
2024-08-03  4:55     ` Christian Hopps
2024-08-02 22:24   ` kernel test robot
2024-08-03  0:27   ` kernel test robot
2024-08-01  8:03 ` [PATCH ipsec-next v7 09/16] xfrm: iptfs: share page fragments of inner packets Christian Hopps
2024-08-01  8:03 ` [PATCH ipsec-next v7 10/16] xfrm: iptfs: add fragmenting of larger than MTU user packets Christian Hopps
2024-08-01  8:03 ` [PATCH ipsec-next v7 11/16] xfrm: iptfs: add basic receive packet (tunnel egress) handling Christian Hopps
2024-08-01  8:03 ` [PATCH ipsec-next v7 12/16] xfrm: iptfs: handle received fragmented inner packets Christian Hopps
2024-08-03  0:38   ` kernel test robot
2024-08-01  8:03 ` [PATCH ipsec-next v7 13/16] xfrm: iptfs: add reusing received skb for the tunnel egress packet Christian Hopps
2024-08-01  8:03 ` [PATCH ipsec-next v7 14/16] xfrm: iptfs: add skb-fragment sharing code Christian Hopps
2024-08-01  8:03 ` [PATCH ipsec-next v7 15/16] xfrm: iptfs: handle reordering of received packets Christian Hopps
2024-08-01  8:03 ` [PATCH ipsec-next v7 16/16] xfrm: iptfs: add tracepoint functionality Christian Hopps

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=20240801121310.GA10274@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=chopps@chopps.org \
    --cc=chopps@labn.net \
    --cc=devel@linux-ipsec.org \
    --cc=netdev@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.