Avoid infinite loop when parsing PFKEY replies
In bgpd, iked, isakmpd, ldpd and sasyncd we have similar code to
parse PFKEY replies from the kernel. To avoid an infinite loop on
malformed replies validate the SADB extension size.
For consistency with the other daemons rewrite the parsing loop of
iked.
sasyncd already validates the extension size, so no change needed.
ok claudio@ tb@ tobhe@
Adjust the adjout_prefix_dump walker to operate using the adjout_bid
and stop using peer_get() in the walker.
This fixes the peer_reaper walker which before this was not working
at all. The peer reaper removed the peer from the RB tree before walking
the table and so peer_get() would return NULL and abort the walk immediatly.
Adjust the adjout_prefix_dump context to use the adjout_bid and stop using
peer->conf.id and peer_get.
To make this work the following changes are needed:
- For the callback drop the struct rde_peer argument instead add a uint32_t
bid argument.
- adjout_prefix_first() also needs to switch to using the adjout bitmask id
instead of using the peer directly.
- also change adjout_prefix_next() just to be in sync with
adjout_prefix_first()
- In most callbacks use the arg pointer to pass in the peer
- Adjust rde_dump_ctx_new() and rde_dump_adjout_upcall(). The latter now
[8 lines not shown]
The extended nexthop capability only works with 'fib-update no'
enfoce this in the parser.
Right now there is no FIB support for IPv6 nexthops for IPv4 routes.
Both the bgpd kroute.c code and the OpenBSD network stack are not ready
for this. This feature is currently only used to allow some IXP to play
with RFC8950 so no FIB support is fine for that use case.
Protect other people from tripping over this thinking there is full support.
Issue brought up by a report from 7Asecurity
OK tb@
Remove sysutils/facette
dormant upstream since 6 years, and marked BROKEN anyway. recommend
grafana instead.
while here fix the XawMu $obsolete_reason entry, should be pkgname not a
pkgpath.
In rde_attr_missing() make sure the nexthop attribute is present if there
is any nlri data. In rde_as4byte_fixup() only run if ATTR_ASPATH is present.
Depending the nexthop attribute on MP_REACH is not correct since and UPDATE
can in theory carry both MP_REACH nlri and old school IPv4 nlri.
rde_as4byte_fixup() should only fixup paths that have
- ATTR_AS4_AGGREGATOR or ATTR_AS4_PATH present
- ATTR_ASPATH must be present as well
- no parse error (F_ATTR_PARSE_ERR)
The rde_as4byte_fixup() is entered all the time even for path that only
contain an ATTR_MP_UNREACH (which then could also include an ATTR_AS4_PATH
but no ATTR_ASPATH).
Reported by 7Asecurity
OK tb@
expect: set channel type to TCL_CHANNEL_VERSION_2 for llvm22
Avoid passing the ExpBlockModeProc function pointer through an object
pointer type and instead move it to the proper place in the struct. Setting
the channel version of expChannelType to 2 in the version field tells tcl's
Tcl_ChannelBlockModeProc() to use the function pointer directly, and avoids
undefined behavior. Using TCL_CHANNEL_VERSION_2 is the conservative choice,
although version 5 would also work.
discussed with stu
tested/ok jca
