[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20201223141441.GB2790422@sasha-vm>
Date: Wed, 23 Dec 2020 09:14:41 -0500
From: Sasha Levin <sashal@...nel.org>
To: Andrea Parri <parri.andrea@...il.com>
Cc: Michael Kelley <mikelley@...rosoft.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
Saruhan Karademir <skarade@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Jakub Kicinski <kuba@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Wei Liu <wei.liu@...nel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>
Subject: Re: [PATCH AUTOSEL 4.14 40/66] hv_netvsc: Validate number of
allocated sub-channels
On Wed, Dec 23, 2020 at 09:59:31AM +0100, Andrea Parri wrote:
>On Wed, Dec 23, 2020 at 02:47:56AM +0000, Michael Kelley wrote:
>> From: Sasha Levin <sashal@...nel.org> Sent: Tuesday, December 22, 2020 6:22 PM
>> >
>> > From: "Andrea Parri (Microsoft)" <parri.andrea@...il.com>
>> >
>> > [ Upstream commit 206ad34d52a2f1205c84d08c12fc116aad0eb407 ]
>> >
>> > Lack of validation could lead to out-of-bound reads and information
>> > leaks (cf. usage of nvdev->chan_table[]). Check that the number of
>> > allocated sub-channels fits into the expected range.
>> >
>> > Suggested-by: Saruhan Karademir <skarade@...rosoft.com>
>> > Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@...il.com>
>> > Reviewed-by: Haiyang Zhang <haiyangz@...rosoft.com>
>> > Acked-by: Jakub Kicinski <kuba@...nel.org>
>> > Cc: "David S. Miller" <davem@...emloft.net>
>> > Cc: Jakub Kicinski <kuba@...nel.org>
>> > Cc: netdev@...r.kernel.org
>> > Link:
>> > https://lore.kernel.org/linux-hyperv/20201118153310.112404-1-parri.andrea@gmail.com/
>> > Signed-off-by: Wei Liu <wei.liu@...nel.org>
>> > Signed-off-by: Sasha Levin <sashal@...nel.org>
>> > ---
>> > drivers/net/hyperv/rndis_filter.c | 5 +++++
>> > 1 file changed, 5 insertions(+)
>> >
>>
>> Sasha -- This patch is one of an ongoing group of patches where a Linux
>> guest running on Hyper-V will start assuming that hypervisor behavior might
>> be malicious, and guards against such behavior. Because this is a new
>> assumption, these patches are more properly treated as new functionality
>> rather than as bug fixes. So I would propose that we *not* bring such patches
>> back to stable branches.
>
>Thank you, Michael. Just to confirm, I agree with Michael's assessment
>above and I join his proposal to *not* backport such patches to stable.
I'll drop it then, thanks.
--
Thanks,
Sasha
Powered by blists - more mailing lists