MSN DC null pointer dereference

[Stu Tomlinson]

On Sun, 2010-12-19 at 15:37 -0500, Elliott Sales de Andrade wrote:
> On Thu, Dec 16, 2010 at 12:52 PM, Elliott Sales de Andrade
> <qulogic at pidgin.im> wrote:
> > On Tue, Dec 14, 2010 at 10:15 PM, Stu Tomlinson <stu at nosnilmot.com> wrote:
> >> Someone more familiar with MSN direct connections would need to
> >> determine why msn_dc_process_packet() is being called with a short
> >> packet. Simple "fix" might be to add NULL check on "part" in
> >> msn_slplink_process_msg() but that smells like papering over the actual
> >> problem.
> >>
> >
> > The simple fix is probably adequate. I will have to take a look at
> > what the official client does and see if it drops the DC back to the
> > old SB connection, or simply ignores the short packets. It may also be
> > that the short packets have some other meaning, but I have not seen
> > any reference to it as yet.
> >
> 
> It appears that we are receiving short packets because the official
> client thinks we implement p2pv2. Obviously, since we don't do that
> yet, it shouldn't be any harm if we just drop those packets.

That's curious, I thought the official client was only sending P2Pv2 to
clients supporting MSNP16, but for the Fedora builds I disabled MSNP16
and use MSNP15 to avoid the regressions in buddy icons, custom
emoticons, etc. that arose from receiving P2Pv2.

Regards,


Stu.