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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 07 Jan 2007 17:11:23 -0800 (PST)
From:	David Miller <>
Subject: Re: Bluetooth fixes for 2.6.20-rc4

From: Marcel Holtmann <>
Date: Mon, 08 Jan 2007 01:31:44 +0100

> Commit: 2b2e64be763c5e64d4ae4a061825b18decf1edf7 
> Author: Marcel Holtmann <> Mon, 08 Jan 2007 01:00:33 +0100 
>     [Bluetooth] Fix uninitialized return value for RFCOMM sendmsg()
>     When calling send() with a zero length parameter on a RFCOMM socket
>     it returns a positive value. In this rare case the variable err is
>     used uninitialized and unfortunately its value is returned.
>     Signed-off-by: Marcel Holtmann <>

You can't fix this bug like that.

If sendmsg() sends any bytes, it should return the number of
bytes sent even if an error occurs mid-stream.

With this change, you'll now return the error instead of
the number of bytes sent.  That's what the new "sent = err"
assignment does.

You have to do sendmsg() with those semantics, or else you lose
information in that the user can never know how many bytes were
actually sent successfully.  Losing the error after successfully sent
bytes is OK, if the error persists the user will get it when it
recalls sendmsg() to push the rest of the remaining bytes out.

The original code tried to do it right.

If the bug is that 'err' is uninitialized, why try to fix this
by being fancy, just initialize it :-)
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists