netdev - An ioctl to delete an ipv6 tunnel leads to a kernel panic

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <32209efe0802111249x16a6bbe0l4c152b3cf3aa0470@mail.gmail.com>
Date:	Mon, 11 Feb 2008 12:49:12 -0800
From:	"Natalie Protasevich" <protasnb@...il.com>
To:	"David Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>
Subject: An ioctl to delete an ipv6 tunnel leads to a kernel panic

Hello,

This bug was reported to bugzilla.kernel.org:

http://bugzilla.kernel.org/show_bug.cgi?id=8895

Hardware Environment:  user mode linux and vmware
Software Environment:   an evolution of mip6d (ip mobility daemon)
Problem Description:     The mip6d HA was modified to make a
redondancy evolution, when an HA is interrupted, the other takes over,
this leads to some
creation/deletion of routes and tunnels.
Note: The HA ip address known by the mobile (MR) stays the same, the
slave HA takes it with an override neighbor advertisement message. So
the tunnel between
the mobile router and the HA(s) keep the same end adresses.
The problem occurs when a Ctrl C is done on the master HA, the slave
takes over but sometimes, the master gets a kernel panic.

Possible reason for this failure was identified and tested by the
submitter and several other reporters that ran into the same problem.
Can the patch be reviewed and pushed upstream if accepted (if the
problem hasn't been addressed already)?

Thanks,
--Natalie
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html