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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 7 Jan 2021 21:36:37 -0500 From: Your Real Name <zhutong@...zon.com> To: David Miller <davem@...emloft.net> CC: <sashal@...nel.org>, <edumazet@...gle.com>, <vvs@...tuozzo.com>, <netdev@...r.kernel.org>, <stable@...r.kernel.org>, <linux-kernel@...r.kernel.org> Subject: Re: [PATCH] neighbour: Disregard DEAD dst in neigh_update On Tue, Jan 05, 2021 at 04:05:21PM -0800, David Miller wrote: > > > From: Tong Zhu <zhutong@...zon.com> > Date: Wed, 30 Dec 2020 17:54:23 -0500 > > > In 4.x kernel a dst in DST_OBSOLETE_DEAD state is associated > > with loopback net_device and leads to loopback neighbour. It > > leads to an ethernet header with all zero addresses. > > > > A very troubling case is working with mac80211 and ath9k. > > A packet with all zero source MAC address to mac80211 will > > eventually fail ieee80211_find_sta_by_ifaddr in ath9k (xmit.c). > > As result, ath9k flushes tx queue (ath_tx_complete_aggr) without > > updating baw (block ack window), damages baw logic and disables > > transmission. > > > > Signed-off-by: Tong Zhu <zhutong@...zon.com> > > Please repost with an appropriate Fixes: tag. > > Thanks. I had a second thought on this. This fix should go mainline too. This is a case we are sending out queued packets when arp reply from the neighbour comes in. With 5.x kernel, a dst in DST_OBSOLETE_DEAD state leads to dropping of this packet. It is not as bad as with 4.x kernel that may end up with an all-zero mac address packet out to ethernet or choking up ath9k when using block ack. Dropping the packet is still wrong. I’ll repost as a fix to mainline and target backport to 4.x LTS releases. Best regards
Powered by blists - more mailing lists