[PATCH rtems-libbsd] ipsec-tools/pfkey: Fix socket leak
Christian MAUDERER
christian.mauderer at embedded-brains.de
Fri May 7 14:54:26 UTC 2021
Hello Joel,
Am 07.05.21 um 16:45 schrieb Joel Sherrill:
>
>
> On Fri, May 7, 2021 at 9:04 AM Christian MAUDERER
> <christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>> wrote:
>
> It is a bit hard to see: The setkey programm uses the functions from
> this library. In pfkey_open, a socket is opened and returned to setkey.
> But setkey never closes it.
>
>
> This much I assumed from the words "socket" and "leak" :)
>
>
> We already have wrappers around all of the "dangerous" functions that
> allocated resources. The wrappers register the resource allocation. If
> an application called with
> rtems_bsd_program_call_main_with_data_restore
> exits, it will close or free the resources.
>
>
> This makes sense. Is this documented?
Like a lot of libbsd: Not really. A rough description of the user-space
utility porting process is here:
https://git.rtems.org/rtems-libbsd/tree/CONTRIBUTING.md#n189
But that is basically a "do it exactly like it is written there" guide
than an explanation. The part that the rtems-bsd-program.h does all of
the magic with the wrappers and registering ressources is clearly
missing. If you know a good location where I should add a bit of
description for this, please let me know.
>
>
> There are some other functions in the pfkey that don't work well with
> that mechanism. Therefore I only added the one function that is
> responsible for the socket leak.
>
>
> How about add some more to the commit message along the lines of
> what you explained here. It just isn't obvious how a change to a macro
> without words like free or deallocate in it fixes anything.
>
I'll do that (most likely) on Monday.
Best regards
Christian
>
> Note that it is a bit of a hack but it works. I have planned to replace
> the ipsec-tools with the tools from racoon2 soon to support newer
> encryption protocols. So I think it's a reasonable intermediate
> solution.
>
>
> OK. One thing we have gotten better at is migrating to pick up better
> things.
>
> --joel
>
>
> Best regards
>
> Christian
>
> Am 07.05.21 um 15:56 schrieb Joel Sherrill:
> > How does this fix a leak?
> >
> > On Fri, May 7, 2021 at 7:09 AM Christian MAUDERER
> > <christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>
> > <mailto:christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>>> wrote:
> >
> > Note that I would like to push this patch on 5-freebsd-12 as
> well as on
> > master.
> >
> > Best regards
> >
> > Christian
> >
> >
> > Am 07.05.21 um 14:08 schrieb Christian Mauderer:
> > > Fixes #4404
> > > ---
> > > ipsec-tools/src/libipsec/pfkey.c | 7 +++++++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/ipsec-tools/src/libipsec/pfkey.c
> > b/ipsec-tools/src/libipsec/pfkey.c
> > > index a621be12..385a21a9 100644
> > > --- a/ipsec-tools/src/libipsec/pfkey.c
> > > +++ b/ipsec-tools/src/libipsec/pfkey.c
> > > @@ -1,5 +1,12 @@
> > > #include <machine/rtems-bsd-user-space.h>
> > >
> > > +#ifdef __rtems__
> > > +/* Only need socket from rtems-bsd-program wrappers! */
> > > +int
> > > +rtems_bsd_program_socket(int domain, int type, int protocol);
> > > +#define socket(domain, type, protocol) \
> > > + rtems_bsd_program_socket(domain, type, protocol)
> > > +#endif /* __rtems__ */
> > > /* $NetBSD: pfkey.c,v 1.21.2.1 2011/11/14 13:25:06
> tteras Exp
> > $ */
> > >
> > > /* $KAME: pfkey.c,v 1.47 2003/10/02 19:52:12 itojun Exp
> $ */
> > >
> >
> > --
> > --------------------------------------------
> > embedded brains GmbH
> > Herr Christian MAUDERER
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>
> > <mailto:christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>>
> > phone: +49-89-18 94 741 - 18
> > fax: +49-89-18 94 741 - 08
> >
> > Registergericht: Amtsgericht München
> > Registernummer: HRB 157899
> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen,
> Thomas Dörfler
> > Unsere Datenschutzerklärung finden Sie hier:
> > https://embedded-brains.de/datenschutzerklaerung/
> <https://embedded-brains.de/datenschutzerklaerung/>
> > <https://embedded-brains.de/datenschutzerklaerung/
> <https://embedded-brains.de/datenschutzerklaerung/>>
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org <mailto:devel at rtems.org> <mailto:devel at rtems.org
> <mailto:devel at rtems.org>>
> > http://lists.rtems.org/mailman/listinfo/devel
> <http://lists.rtems.org/mailman/listinfo/devel>
> > <http://lists.rtems.org/mailman/listinfo/devel
> <http://lists.rtems.org/mailman/listinfo/devel>>
> >
>
> --
> --------------------------------------------
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>
> phone: +49-89-18 94 741 - 18
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> <https://embedded-brains.de/datenschutzerklaerung/>
>
--
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
phone: +49-89-18 94 741 - 18
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
More information about the devel
mailing list