netdev - Re: Fw: [Bug 214619] New: Aquantia / Atlantic driver not loading post 5.14.RC7

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]

Message-ID: <ea15681a-01b8-c6c5-a2c6-d1c255a03d4e@marvell.com>
Date:   Fri, 19 Nov 2021 09:58:25 +0100
From:   Igor Russkikh <irusskikh@...vell.com>
To:     Stephen Hemminger <stephen@...workplumber.org>,
        <netdev@...r.kernel.org>
Subject: Re: Fw: [Bug 214619] New: Aquantia / Atlantic driver not loading post
 5.14.RC7

Hello community,

>             Bug ID: 214619
>            Summary: Aquantia / Atlantic driver not loading post 5.14.RC7
>            Product: Networking
>            Version: 2.5
>     Kernel Version: 514.rc7
>           Hardware: x86-64
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: high
>           Priority: P1
>          Component: Other
>           Assignee: stephen@...workplumber.org
>           Reporter: Miles.Rumppe@...il.com
>         Regression: No
> 

https://bugzilla.kernel.org/show_bug.cgi?id=214619

Quite a strange issue, we are looking for advice/assistance.

After looking into disassembly, I see the failure is AFTER the end of the function:

    272d:       b8 01 00 00 00          mov    $0x1,%eax
    2732:       d3 e0                   shl    %cl,%eax
    2734:       41 09 85 f8 05 00 00    or     %eax,0x5f8(%r13)
    273b:       eb 84                   jmp    26c1 <aq_nic_start+0x301>
>>  273d:       0f 0b                   ud2    

    273f:       90                      nop

On undefined instruction.

We had similar report in past from another user, but were unable to find out how execution could reach that point.

I suspect this is something related to compiler optimization or some other coincidence.

We also were not successful in trying to bisect this driver specific changes. Looks like some side kernel change could have triggered that.

Any clue?

Regards,
  Igor