linux-kernel - [PATCH V2] net: qrtr: use protocol endiannes variable

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

Message-Id: <1557536193-11949-1-git-send-email-hofrat@osadl.org>
Date:   Sat, 11 May 2019 02:56:33 +0200
From:   Nicholas Mc Guire <hofrat@...dl.org>
To:     "David S. Miller" <davem@...emloft.net>
Cc:     Arun Kumar Neelakantam <aneela@...eaurora.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Anshuman Khandual <anshuman.khandual@....com>,
        David Hildenbrand <david@...hat.com>,
        Arnd Bergmann <arnd@...db.de>,
        Johannes Berg <johannes.berg@...el.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Nicholas Mc Guire <hofrat@...dl.org>
Subject: [PATCH V2] net: qrtr: use protocol endiannes variable

sparse was unable to verify endiannes correctness due to reassignment
from le32_to_cpu to the same variable - fix this warning up by providing
a proper __le32 type and initializing it. This is not actually fixing
any bug - rather just addressing the sparse warning.

Signed-off-by: Nicholas Mc Guire <hofrat@...dl.org>
---

Problem located by an experimental coccinelle script to locate
patters that make sparse unhappy (false positives):

V2: Reorder variables to preserve reverse christmas tree ordering
    as requested by David Miller <davem@...emloft.net>.

sparse was unhappy about:
net/qrtr/qrtr.c:811:24: warning: cast to restricted __le32

The patch does change the binary - from inspection of the .lst files
it seems that the additional variable as well instruction reordering
constraints change the code even if the code-logic is the same.

Patch was compile-tested with: qcom_defconfig + QRTR=m
(with some unrelated warnings about not implemented system calls)

Patch is against 5.1 (localversion-next is next-20190510)

 net/qrtr/qrtr.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
index dd0e97f..801872a 100644
--- a/net/qrtr/qrtr.c
+++ b/net/qrtr/qrtr.c
@@ -728,12 +728,13 @@ static int qrtr_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)
 	DECLARE_SOCKADDR(struct sockaddr_qrtr *, addr, msg->msg_name);
 	int (*enqueue_fn)(struct qrtr_node *, struct sk_buff *, int,
 			  struct sockaddr_qrtr *, struct sockaddr_qrtr *);
+	__le32 qrtr_type = cpu_to_le32(QRTR_TYPE_DATA);
 	struct qrtr_sock *ipc = qrtr_sk(sock->sk);
 	struct sock *sk = sock->sk;
 	struct qrtr_node *node;
 	struct sk_buff *skb;
+	u32 type = 0;
 	size_t plen;
-	u32 type = QRTR_TYPE_DATA;
 	int rc;
 
 	if (msg->msg_flags & ~(MSG_DONTWAIT))
@@ -807,8 +808,8 @@ static int qrtr_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)
 		}
 
 		/* control messages already require the type as 'command' */
-		skb_copy_bits(skb, 0, &type, 4);
-		type = le32_to_cpu(type);
+		skb_copy_bits(skb, 0, &qrtr_type, 4);
+		type = le32_to_cpu(qrtr_type);
 	}
 
 	rc = enqueue_fn(node, skb, type, &ipc->us, addr);
-- 
2.1.4