mbox series

[SRU,T/X/B/C/D,0/1] CVE-2019-3459 - Heap address infoleak in use of l2cap_get_conf_opt

Message ID 20190219104856.29208-1-kai.heng.feng@canonical.com
Headers show
Series CVE-2019-3459 - Heap address infoleak in use of l2cap_get_conf_opt | expand

Message

Kai-Heng Feng Feb. 19, 2019, 10:48 a.m. UTC 
Heap data infoleak in multiple locations including
functionl2cap_parse_conf_rsp

The fix itself is quite trivial, quote the commit message:
"To prevent any potential leak of heap memory, it is enough to check
that the resulting len calculation after calling l2cap_get_conf_opt is
not below zero. A well formed packet will always return >= 0 here and
will end with the length value being zero after the last option has been
parsed. In case of malformed packets messing with the opt->len field the
length value will become negative. If that is the case, then just abort
and ignore the option."

Marcel Holtmann (1):
  Bluetooth: Verify that l2cap_get_conf_opt provides large enough buffer

 net/bluetooth/l2cap_core.c | 6 ++++++
 1 file changed, 6 insertions(+)

Comments

Kai-Heng Feng Feb. 19, 2019, 10:51 a.m. UTC | #1 
> On Feb 19, 2019, at 11:48 AM, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:
> 
> Heap data infoleak in multiple locations including
> functionl2cap_parse_conf_rsp

Copy-paste the wrong discription, it should be
"Heap address infoleak in use of l2cap_get_conf_opt”
instead.

Kai-Heng

> 
> The fix itself is quite trivial, quote the commit message:
> "To prevent any potential leak of heap memory, it is enough to check
> that the resulting len calculation after calling l2cap_get_conf_opt is
> not below zero. A well formed packet will always return >= 0 here and
> will end with the length value being zero after the last option has been
> parsed. In case of malformed packets messing with the opt->len field the
> length value will become negative. If that is the case, then just abort
> and ignore the option."
> 
> Marcel Holtmann (1):
>  Bluetooth: Verify that l2cap_get_conf_opt provides large enough buffer
> 
> net/bluetooth/l2cap_core.c | 6 ++++++
> 1 file changed, 6 insertions(+)
> 
> -- 
> 2.17.1
> 
> 
> -- 
> kernel-team mailing list
> kernel-team@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team
Seth Forshee Feb. 20, 2019, 11:25 a.m. UTC | #2 
On Tue, Feb 19, 2019 at 06:48:55PM +0800, Kai-Heng Feng wrote:
> Heap data infoleak in multiple locations including
> functionl2cap_parse_conf_rsp
> 
> The fix itself is quite trivial, quote the commit message:
> "To prevent any potential leak of heap memory, it is enough to check
> that the resulting len calculation after calling l2cap_get_conf_opt is
> not below zero. A well formed packet will always return >= 0 here and
> will end with the length value being zero after the last option has been
> parsed. In case of malformed packets messing with the opt->len field the
> length value will become negative. If that is the case, then just abort
> and ignore the option."

Looks reasonable.

Acked-by: Seth Forshee <seth.forshee@canonical.com>

Applied to disco/master-next and unstable/master, thanks!