netdev - Re: Fw: [Bug 219766] New: Garbage Ethernet Frames

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: <Z7SlggSKBDk2wDj-@shredder>
Date: Tue, 18 Feb 2025 17:21:38 +0200
From: Ido Schimmel <idosch@...sch.org>
To: Xin Long <lucien.xin@...il.com>
Cc: Stephen Hemminger <stephen@...workplumber.org>, edumazet@...gle.com,
	netdev@...r.kernel.org, fmei@....com, Wei Wang <weiwan@...gle.com>
Subject: Re: Fw: [Bug 219766] New: Garbage Ethernet Frames

On Mon, Feb 17, 2025 at 05:31:16PM -0500, Xin Long wrote:
> On Sat, Feb 15, 2025 at 3:47 PM Ido Schimmel <idosch@...sch.org> wrote:
> > Another possible solution is to have the blackhole device consume the
> > packets instead of letting them go out without an Ethernet header [4].
> > Doesn't seem great as the packets disappear without telling anyone
> > (before 22600596b675 an error was returned).
> This looks fine to me. The fix in commit 22600596b675 was specifically
> intended to prevent an error from being returned in these cases, as it
> would break userspace UDP applications.

Yes, I later realized that this is fine as well. Packets are already
discarded today via dst_discard_out() if dst_dev_put() was called on a
dst entry before calling dst_output():

# bpftrace -e 'k:dst_discard_out { @[kstack()] = count(); }'
Attaching 1 probe...
^C

@[
    dst_discard_out+5
    ip_send_skb+25
    udp_send_skb+376
    udp_sendmsg+2516
    sock_write_iter+365
    vfs_write+937
    ksys_write+200
    do_syscall_64+158
    entry_SYSCALL_64_after_hwframe+119
]: 2034

While running the reproducer I shared earlier.

> If you prefer to avoid silent drops, you could add a warning like:
> 
>   net_warn_ratelimited("%s(): Dropping skb.\n", __func__);
> 
> similar to how blackhole_netdev_xmit() handles it.

I would like to avoid spamming the kernel log with these messages. I
checked and we see these messages on a few machines while running the
IPv6 torture tests in fib_nexthops.sh. Maybe in net-next I will add a
new drop reason for these scenarios.

> Thanks.

Thanks. I will run this patch through regression and post later this
week if everything is fine.