Re: CVE request: remote heap overflow in linux networking stack

[Andrej Nemec <anemec () redhat com>]

Hello Alexander, Jason,

This is the issue that I referenced in [1]. We have internally decided
that it's worth to assign a CVE even though it's public and there is a
risk of duplication because the issue looks serious. I sent a CVE update
to Mitre, we'll see if they catch it and stop possible duplication
assignment.

All credits for this discovery go to Jason.

[1] http://seclists.org/oss-sec/2017/q2/119

Best Regards,

-- 
Andrej Nemec, Red Hat Product Security
3701 3214 E472 A9C3 EFBE 8A63 8904 44A1 D57B 6DDA


On 04/24/2017 08:17 PM, Solar Designer wrote:
> Hi Jason,
>
> On Mon, Apr 24, 2017 at 08:00:10PM +0200, Jason A. Donenfeld wrote:
> > Requesting a CVE for [1], a heap overflow I found in Linux.
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=4d6fa57b4dab0d77f4d8e9d9c73d1e63f6fe8fee
> Thank you for bringing this in here.
>
> I've attached the above URL's content in text/plain form, as required by
> oss-security content guidelines (actual content must be on the list, not
> only included by reference).
>
> The bug is in drivers/net/macsec.c implementing IEEE 802.1AE (MACsec).
> I hope it is rarely used and thus rarely exposed, and Linux kernel
> support for it is rather new, right?
>
> oss-security is no longer a place to request CVE IDs.  You may request a
> CVE ID directly from MITRE:
>
> https://cveform.mitre.org
>
> Once you have the CVE ID, please post it to this same thread in here.
>
> (For non-public issues, it is also still possible to request CVE IDs
> along with notification to the (linux-)distros lists, as long as the
> primary purpose of giving advance notice to the distros is providing
> them with actionable information.  A few of the distros are CNAs, so
> they'd assign CVE IDs from their pools.)
>
> Alexander

Attachment: signature.asc
Description: OpenPGP digital signature