From: Jason Wang <jasowang@redhat.com>
To: "Mauro Matteo Cascella" <mcascell@redhat.com>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Peter Maydell" <peter.maydell@linaro.org>
Cc: pgn@zju.edu.cn, QEMU Developers <qemu-devel@nongnu.org>,
Finn Thain <fthain@telegraphics.com.au>,
Laurent Vivier <laurent@vivier.eu>
Subject: Re: [PATCH] hw/net/dp8393x: fix integer underflow in dp8393x_do_transmit_packets()
Date: Tue, 1 Dec 2020 13:46:09 +0800 [thread overview]
Message-ID: <cc15cf81-aaf9-0886-b988-61b6314648b9@redhat.com> (raw)
In-Reply-To: <CAA8xKjXJq00HtKNJc0HVAhXXftFHEGLj_KXaiy7M9_2WvgNRrQ@mail.gmail.com>
On 2020/11/30 下午8:11, Mauro Matteo Cascella wrote:
> On Mon, Nov 30, 2020 at 11:44 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>> +Laurent/Finn
>>
>> On 11/24/20 10:24 AM, Mauro Matteo Cascella wrote:
>>> An integer underflow could occur during packet transmission due to 'tx_len' not
>>> being updated if SONIC_TFC register is set to zero. Check for negative 'tx_len'
>>> when removing existing FCS.
>>>
>>> RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1899722
>>> Signed-off-by: Mauro Matteo Cascella <mcascell@redhat.com>
>>> Reported-by: Gaoning Pan <pgn@zju.edu.cn>
>>> ---
>>> hw/net/dp8393x.c | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/hw/net/dp8393x.c b/hw/net/dp8393x.c
>>> index 674b04b354..205c0decc5 100644
>>> --- a/hw/net/dp8393x.c
>>> +++ b/hw/net/dp8393x.c
>>> @@ -495,6 +495,10 @@ static void dp8393x_do_transmit_packets(dp8393xState *s)
>>> } else {
>>> /* Remove existing FCS */
>>> tx_len -= 4;
>>> + if (tx_len < 0) {
>>> + SONIC_ERROR("tx_len is %d\n", tx_len);
>>> + break;
>>> + }
>>> }
>>>
>>> if (s->regs[SONIC_RCR] & (SONIC_RCR_LB1 | SONIC_RCR_LB0)) {
>>>
>> Doesn't it make more sense to check 'tx_len >= 4'
>> and skip tx/rx when 'tx_len == 0'?
>>
> Yes, it makes sense. I thought that skipping tx/rx in case of null
> 'tx_len' could lead to potential inconsistencies when writing the
> status or reading the footer of the packet. but I'm not really sure. I
> can send a new version of the patch if needed, otherwise feel free to
> apply your changes. Thank you.
I think we can go with this patch first and tweak on top consider it's
near the release. So:
Acked-by: Jason Wang <jasowang@redhat.com>
Peter, do you want to merge this patch?
Thanks
>
>> -- >8 --
>> @@ -488,25 +488,29 @@ static void
>> dp8393x_do_transmit_packets(dp8393xState *s)
>> }
>> }
>>
>> - /* Handle Ethernet checksum */
>> - if (!(s->regs[SONIC_TCR] & SONIC_TCR_CRCI)) {
>> - /* Don't append FCS there, to look like slirp packets
>> - * which don't have one */
>> - } else {
>> - /* Remove existing FCS */
>> - tx_len -= 4;
>> + if (tx_len >= 4) {
>> + /* Handle Ethernet checksum */
>> + if (!(s->regs[SONIC_TCR] & SONIC_TCR_CRCI)) {
>> + /* Don't append FCS there, to look like slirp packets
>> + * which don't have one */
>> + } else {
>> + /* Remove existing FCS */
>> + tx_len -= 4;
>> + }
>> }
>>
>> - if (s->regs[SONIC_RCR] & (SONIC_RCR_LB1 | SONIC_RCR_LB0)) {
>> - /* Loopback */
>> - s->regs[SONIC_TCR] |= SONIC_TCR_CRSL;
>> - if (nc->info->can_receive(nc)) {
>> - s->loopback_packet = 1;
>> - nc->info->receive(nc, s->tx_buffer, tx_len);
>> + if (tx_len > 0) {
>> + if (s->regs[SONIC_RCR] & (SONIC_RCR_LB1 | SONIC_RCR_LB0)) {
>> + /* Loopback */
>> + s->regs[SONIC_TCR] |= SONIC_TCR_CRSL;
>> + if (nc->info->can_receive(nc)) {
>> + s->loopback_packet = 1;
>> + nc->info->receive(nc, s->tx_buffer, tx_len);
>> + }
>> + } else {
>> + /* Transmit packet */
>> + qemu_send_packet(nc, s->tx_buffer, tx_len);
>> }
>> - } else {
>> - /* Transmit packet */
>> - qemu_send_packet(nc, s->tx_buffer, tx_len);
>> }
>> s->regs[SONIC_TCR] |= SONIC_TCR_PTX;
>>
>> ---
>>
> Regards,
next prev parent reply other threads:[~2020-12-01 5:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-24 9:24 [PATCH] hw/net/dp8393x: fix integer underflow in dp8393x_do_transmit_packets() Mauro Matteo Cascella
2020-11-30 10:44 ` Philippe Mathieu-Daudé
2020-11-30 12:11 ` Mauro Matteo Cascella
2020-12-01 5:46 ` Jason Wang [this message]
2020-12-01 12:09 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cc15cf81-aaf9-0886-b988-61b6314648b9@redhat.com \
--to=jasowang@redhat.com \
--cc=f4bug@amsat.org \
--cc=fthain@telegraphics.com.au \
--cc=laurent@vivier.eu \
--cc=mcascell@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=pgn@zju.edu.cn \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).