netdev - Re: [PATCH] r8169: Apply configurations to the L0s/L1 entry delay of RTL8105e and RTL8401

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>] [day] [month] [year] [list]

Date:   Sat, 20 Nov 2021 07:54:43 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Q1IQ Fu <fufuyqqqqqq@...il.com>, Jakub Kicinski <kuba@...nel.org>,
        David Miller <davem@...emloft.net>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH] r8169: Apply configurations to the L0s/L1 entry delay of
 RTL8105e and RTL8401

On 20.11.2021 07:41, Q1IQ Fu wrote:
> Thank you very much for your attention. We detected the presence of these two bugs through our new vulnerability scanning technology. We think there may be a security issue, if not, please ignore it.
> 
What exactly is the security issue and how could it be exploited?
It's not the first time that I see a patch submitted based solely on the output of obscure tools.
Always check the result of tools, and you should be able to explain and interpret the tool output.
Especially you should be able to see whether a warning is a false positive.

> Heiner Kallweit <hkallweit1@...il.com <mailto:hkallweit1@...il.com>> 于2021年11月20日周六 上午4:06写道：
> 
>     On 19.11.2021 19:47, Yeqi Fu wrote:
>     > We properly configure the L0s/L1 entry delay in the startup functions of
>     > RTL8105e and RTL8401 through rtl_set_def_aspm_entry_latency(), which will
>     > avoid local denial of service.
>     >
> 
>     What do you mean with local denial of service? Are you aware of any issues
>     with these two chip versions?
> 
>     Where do you got the info from that these calls are appropriate? At least
>     for RTL8401 even the r8101 vendor driver doesn't do it.
> 
>     Your patch misses the net vs. net-next annotation. Is this supposed to be
>     a fix? Then a Fixes tag would be needed.
> 
>     > Signed-off-by: Yeqi Fu <fufuyqqqqqq@...il.com <mailto:fufuyqqqqqq@...il.com>>
>     > ---
>     >  drivers/net/ethernet/realtek/r8169_main.c | 2 ++
>     >  1 file changed, 2 insertions(+)
>     >
>     > diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
>     > index bbe21db20417..4f533007a456 100644
>     > --- a/drivers/net/ethernet/realtek/r8169_main.c
>     > +++ b/drivers/net/ethernet/realtek/r8169_main.c
>     > @@ -3420,6 +3420,7 @@ static void rtl_hw_start_8401(struct rtl8169_private *tp)
>     >               { 0x07, 0xffff, 0x8e68 },
>     >       };
>     > 
>     > +     rtl_set_def_aspm_entry_latency(tp);
>     >       rtl_ephy_init(tp, e_info_8401);
>     >       RTL_W8(tp, Config3, RTL_R8(tp, Config3) & ~Beacon_en);
>     >  }
>     > @@ -3437,6 +3438,7 @@ static void rtl_hw_start_8105e_1(struct rtl8169_private *tp)
>     >               { 0x0a, 0, 0x0020 }
>     >       };
>     > 
>     > +     rtl_set_def_aspm_entry_latency(tp);
>     >       /* Force LAN exit from ASPM if Rx/Tx are not idle */
>     >       RTL_W32(tp, FuncEvent, RTL_R32(tp, FuncEvent) | 0x002800);
>     > 
>     >
>