On Mon, 3 Apr 2023 20:47:01 -0600
David Ahern wrote:
> On 4/3/23 9:24 AM, Stephen Hemminger wrote:
> > ted
> >>
> >> This happens because iproute2 just assumes the tunnel is ipv4, but the
> >> kernel "knows" it's actually ip6gre so when calling the SIOCGETTUNNEL
> >> ioctl it writes back a stru
On Mon, 3 Apr 2023 20:47:01 -0600
David Ahern wrote:
> On 4/3/23 9:24 AM, Stephen Hemminger wrote:
> > ted
> >>
> >> This happens because iproute2 just assumes the tunnel is ipv4, but the
> >> kernel "knows" it's actually ip6gre so when calling the SIOCGETTUNNEL
> >> ioctl it writes back a stru
On 4/3/23 9:24 AM, Stephen Hemminger wrote:
> ted
>>
>> This happens because iproute2 just assumes the tunnel is ipv4, but the
>> kernel "knows" it's actually ip6gre so when calling the SIOCGETTUNNEL
>> ioctl it writes back a struct ip6_tnl_parm2 into the struct
>> ip_tunnel_parm which is smaller,
ted
>
> This happens because iproute2 just assumes the tunnel is ipv4, but the
> kernel "knows" it's actually ip6gre so when calling the SIOCGETTUNNEL
> ioctl it writes back a struct ip6_tnl_parm2 into the struct
> ip_tunnel_parm which is smaller, so the stack gets overwritten. Is
> there any way
On Mon, 3 Apr 2023 at 15:56, Stephen Hemminger
wrote:
>
> On Sun, 2 Apr 2023 23:58:52 +0100
> Luca Boccassi wrote:
>
> > On Sat, 25 Mar 2023 at 00:39, Bernhard Übelacker
> > wrote:
> > >
> > > Dear Maintainer,
> > > I tried to find out where exactly the stack smashing takes place.
> > > And fou
On Sun, 2 Apr 2023 23:58:52 +0100
Luca Boccassi wrote:
> On Sat, 25 Mar 2023 at 00:39, Bernhard Übelacker
> wrote:
> >
> > Dear Maintainer,
> > I tried to find out where exactly the stack smashing takes place.
> > And found the ioctl SIOCCHGTUNNEL did write more than the 52 bytes
> > allocated
On Sat, 25 Mar 2023 at 00:39, Bernhard Übelacker wrote:
>
> Dear Maintainer,
> I tried to find out where exactly the stack smashing takes place.
> And found the ioctl SIOCCHGTUNNEL did write more than the 52 bytes
> allocated in variable old_p, by that overwriting the stack canary.
>
> Kind regard
Dear Maintainer,
I tried to find out where exactly the stack smashing takes place.
And found the ioctl SIOCCHGTUNNEL did write more than the 52 bytes
allocated in variable old_p, by that overwriting the stack canary.
Kind regards,
Bernhard
(gdb)
0x5557589f 62 {
1: x/i $pc
=> 0
Package: iproute2
Version: 5.10.0-4
Severity: normal
Dear Maintainer,
I just came across a "stack smashing detected" crash when changing a gre6 to a
gre4 tunnel
To reproduce create an ipv6 gre tunnel:
> ip tunnel add gre1 mode ip6gre local 2001:db8::1 remote 2001:db8::2 ttl 255
And then attempt
9 matches
Mail list logo
