Date:   Wed, 23 Jan 2019 13:37:04 +0200
From:   Johan Hedberg <johan.hedberg@gmail.com>
To:     Marcel Holtmann <marcel@holtmann.org>
Cc:     linux-bluetooth@vger.kernel.org, gregkh@linuxfoundation.org
Subject: Re: [PATCH] Bluetooth: Verify that l2cap_get_conf_opt provides large
 enough buffer
Message-ID: <20190123113704.GB11718@fcahill-mobl1.ger.corp.intel.com>
Mail-Followup-To: Marcel Holtmann <marcel@holtmann.org>,
        linux-bluetooth@vger.kernel.org, gregkh@linuxfoundation.org
References: <20190118124319.12187-1-marcel@holtmann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190118124319.12187-1-marcel@holtmann.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Marcel,

On Fri, Jan 18, 2019, Marcel Holtmann wrote:
> The function l2cap_get_conf_opt will return L2CAP_CONF_OPT_SIZE + opt->len
> as length value. The opt->len however is in control over the remote user
> and can be used by an attacker to gain access beyond the bounds of the
> actual packet.
> 
> 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.
> 
> In case an attacker uses a too short opt->len value, then garbage will
> be parsed, but that is protected by the unknown option handling and also
> the option parameter size checks.
> 
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
>  net/bluetooth/l2cap_core.c | 6 ++++++
>  1 file changed, 6 insertions(+)

Applied to bluetooth-next. Thanks.

Johan