Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PATCH] Bluetooth: vhci: Fix info leak in force_devcd_write()
From:   patchwork-bot+bluetooth@kernel.org
Message-Id: <168150302013.15322.10506281113817205664.git-patchwork-notify@kernel.org>
Date:   Fri, 14 Apr 2023 20:10:20 +0000
References: <634ab328-3ef2-43b7-8f81-8a48c7661427@kili.mountain>
In-Reply-To: <634ab328-3ef2-43b7-8f81-8a48c7661427@kili.mountain>
To:     Dan Carpenter <error27@gmail.com>
Cc:     mmandlik@google.com, johan.hedberg@gmail.com, luiz.dentz@gmail.com,
        linux-bluetooth@vger.kernel.org, kernel-janitors@vger.kernel.org
Precedence: bulk

Hello:

This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Thu, 6 Apr 2023 11:55:17 +0300 you wrote:
> There are a number of bugs here:
> 
> 1) If "count" is less than sizeof(dump_data.data) then it copies
>    uninitialized data.
> 2) If simple_write_to_buffer() returns -EFAULT then we run into a
>    problem "ret < count" comparison.  "count" is an unsigned long so the
>    comparison is type promoted to unsigned long and the negative returns
>    become high positive values.  That also results in copying
>    uninitialized data.
> 3) If "*ppos" is non-zero then the first part of the dump_data
>    buffer is uninitialized.  Using copy_from_user() instead of
>    simple_write_to_buffer() is more appropriate here.
> 
> [...]

Here is the summary with links:
  - Bluetooth: vhci: Fix info leak in force_devcd_write()
    https://git.kernel.org/bluetooth/bluetooth-next/c/0b1900708232

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html