linux-kernel - [PATCH] platform/surface: aggregator: Fix braces in if condition with unlikely() macro

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: <20210126172202.1428367-1-luzmaximilian@gmail.com>
Date:   Tue, 26 Jan 2021 18:22:02 +0100
From:   Maximilian Luz <luzmaximilian@...il.com>
To:     platform-driver-x86@...r.kernel.org
Cc:     Maximilian Luz <luzmaximilian@...il.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Mark Gross <mgross@...ux.intel.com>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        linux-kernel@...r.kernel.org
Subject: [PATCH] platform/surface: aggregator: Fix braces in if condition with unlikely() macro

The braces of the unlikely() macro inside the if condition only cover
the subtraction part, not the whole statement. This causes the result of
the subtraction to be converted to zero or one. While that still works
in this context, it causes static analysis tools to complain (and is
just plain wrong).

Fix the bracket placement and, while at it, simplify the if-condition.
Also add a comment to the if-condition explaining what we expect the
result to be and what happens on the failure path, as it seems to have
caused a bit of confusion.

This commit should not cause any difference in behavior or generated
code.

Reported-by: Dan Carpenter <dan.carpenter@...cle.com>
Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem")
Signed-off-by: Maximilian Luz <luzmaximilian@...il.com>
---
 .../surface/aggregator/ssh_packet_layer.c     | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/surface/aggregator/ssh_packet_layer.c b/drivers/platform/surface/aggregator/ssh_packet_layer.c
index 74f0faaa2b27..583315db8b02 100644
--- a/drivers/platform/surface/aggregator/ssh_packet_layer.c
+++ b/drivers/platform/surface/aggregator/ssh_packet_layer.c
@@ -1694,7 +1694,24 @@ static size_t ssh_ptl_rx_eval(struct ssh_ptl *ptl, struct ssam_span *source)
 	/* Find SYN. */
 	syn_found = sshp_find_syn(source, &aligned);
 
-	if (unlikely(aligned.ptr - source->ptr) > 0) {
+	if (unlikely(aligned.ptr != source->ptr)) {
+		/*
+		 * We expect aligned.ptr == source->ptr. If this is not the
+		 * case, then aligned.ptr > source->ptr and we've encountered
+		 * some unexpected data where we'd expect the start of a new
+		 * message (i.e. the SYN sequence).
+		 *
+		 * This can happen when a CRC check for the previous message
+		 * failed and we start actively searching for the next one
+		 * (via the call to sshp_find_syn() above), or the first bytes
+		 * of a message got dropped or corrupted.
+		 *
+		 * In any case, we issue a warning, send a NAK to the EC to
+		 * request re-transmission of any data we haven't acknowledged
+		 * yet, and finally, skip everything up to the next SYN
+		 * sequence.
+		 */
+
 		ptl_warn(ptl, "rx: parser: invalid start of frame, skipping\n");
 
 		/*
-- 
2.30.0