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] [thread-next>] [day] [month] [year] [list]
Message-Id: <20220330123027.25897-1-xiam0nd.tong@gmail.com>
Date:   Wed, 30 Mar 2022 20:30:27 +0800
From:   Xiaomeng Tong <xiam0nd.tong@...il.com>
To:     leon@...nel.org
Cc:     bharat@...lsio.com, jgg@...pe.ca, linux-kernel@...r.kernel.org,
        linux-rdma@...r.kernel.org, roland@...estorage.com,
        stable@...r.kernel.org, vipul@...lsio.com, xiam0nd.tong@...il.com
Subject: Re: [PATCH] cxgb4: cm: fix a incorrect NULL check on list iterator

On Sun, 27 Mar 2022 19:38:31 +0300, Leon Romanovsky wrote:
> 
> On Sun, Mar 27, 2022 at 03:35:42PM +0800, Xiaomeng Tong wrote:
> > The bug is here:
> > 	if (!pdev) {
> > 
> > The list iterator value 'pdev' will *always* be set and non-NULL
> > by for_each_netdev(), so it is incorrect to assume that the
> > iterator value will be NULL if the list is empty or no element
> > found (in this case, the check 'if (!pdev)' can be bypassed as
> > it always be false unexpectly).
> > 
> > To fix the bug, use a new variable 'iter' as the list iterator,
> > while use the original variable 'pdev' as a dedicated pointer to
> > point to the found element.
> 
> I don't think that the description is correct.
> We are talking about loopback interface which received packet, the pdev will always exist.

Do the both conditions impossible?
1. the list is empty or
2. we can not found a pdev due to this check
	if (ipv6_chk_addr(&init_net,
  			  (struct in6_addr *)peer_ip,
			  pdev, 1))
			  iter, 1))

> Most likely. the check of "if (!pdev)" is to catch impossible situation where IPV6 packet
> was sent over loopback, but IPV6 is not enabled.

--
Xiaomeng Tong

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ