PROBLEM: regression in ipv6 / udpv6_sendmsg between 3.2/3.3 kernels, causing panics

Good day,

Local IPv6-enabled system suffers from really frequent (but somewhat random)
kernel panics, with mainline kernel versions, starting from 3.3, always
featuring udpv6_sendmsg in the produced stack trace.

Machine in question acts like an internet gateway, hosting quite a few services
as well, traffic goes through it as well as originates from it.

It is connected to IPv6 via sit tunnel over regular ISP-provided IPv4 connection.

First time I've seen this error was just a few seconds after network was
configured on first boot with 3.3 kernel.
I've tried updating kernel to later 3.3.X versions and 3.4 series (stack trace
captured is from 3.4.2).
Machine worked months with different 3.2.X kernels (starting from 3.2, latest
being 3.2.16) with no problems of this kind whatsoever (no major kernel errors
like oops, bug or panic).

Panic seem to happen reliably within 12 hours of booting kernel 3.3+ and
enabling ipv6 sit tunnel to the outside world.
So far, I've seen about 5-10 of these and they always feature udpv6_sendmsg
somewhere at the top.
Latest traceback (with 3.4.2, ver_linux output attached as well) on a laptop
camera and is attached.

I've tried reproducing it on local ipv6 network with iperf-generated udp traffic
(since there doesn't seem to be any local ipv6/udp services on the machine) with
no luck thus far.

In most cases, mainline (Linus tree) kernel versions from kernel.org were used
with AppArmor userspace compatibility patches
(http://wiki.apparmor.net/index.php/Main_Page#Userspace, included in the
archive).
Seeing apparmor calls in the stack traces (and since no apparmor profiles are
used on this machine), I've tried disabling AppArmor LSM, but eventually got the
same panic.

Hardware is a low-spec commodity amd64 Intel Atom miniITX platform.
Kernel config and hardware information attached.

Only workarounds I've been able to find so far is running 3.2.X kernels or
disabling sit tunnel (and IPv6 connectivity), but both seem to be far from
perfect.

Bisection doesn't seem to be an easy option, because error seem to be fairly
random, not triggered by just any udp traffic.

Can someone maybe point out specific commits I can try to revert, to see if
it'll solve the issue?
I haven't looked at the changes to the relevant code paths in 3.2-3.3 timeframe
myself yet, but intend to try eventually, though I'm not familiar enough with
the kernel architecture and code to make much sense of it, I'm afraid.

Thanks in advance for any assistance.