netdev - Re: [EXT] [PATCH] [net][atlantic] Fix buff_ring OOB in aq_ring_rx

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 12 Jul 2021 13:36:19 -0400
From:   Zekun Shen <bruceshenzk@...il.com>
To:     Igor Russkikh <irusskikh@...vell.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [EXT] [PATCH] [net][atlantic] Fix buff_ring OOB in
 aq_ring_rx_clean

On Mon, Jul 12, 2021 at 06:33:37PM +0200, Igor Russkikh wrote:
> From code analysis, the only way how ->next could be overflowed - is a
> hardware malfunction/data corruption.
Yes. The unchecked index field is within a buffer ring, which I assume is a DMA region.
A faulty or compromised hardware could trigger the OOB bug. Leaving it undetected could
cause memory corruption, so the patch returns with I/O error.

> Software driver logic can't lead to that field overflow.
> I'm not sure how fuzzing can lead to that result.. Do you have any details?
The fuzzer we used is targeting the hardware input vector including MMIO and DMA.

> Even if it can, then we should also do a similar check in `if (buff->is_eop)` case below,
> since it also uses similar sequence to run through `next` pointers.
Thanks for pointing out. That should be checked too.