linux-cifs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve French <smfrench@gmail.com>
To: CIFS <linux-cifs@vger.kernel.org>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Pavel Shilovsky <piastryyy@gmail.com>
Subject: Re: [PATCH][SMB3] remove confusing dmesg when mounting with encryption
Date: Fri, 8 Nov 2019 01:07:47 -0600	[thread overview]
Message-ID: <CAH2r5mtZhTx2nX1aTrMfBXY=QZKars-P8MzsnxAA1-EARKZddg@mail.gmail.com> (raw)
In-Reply-To: <CAH2r5muzbhS6=G+A9rPNerH+H2FLHFb=TgcMe28=2qgU-WvG4A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

Here is updated patch which following Pavel's suggestion simply
removes the sometimes confusing warning rather than make a more
complex change which checks for whether the packet was decrypted
earlier or not


On Tue, Nov 5, 2019 at 4:47 PM Steve French <smfrench@gmail.com> wrote:
>
> The smb2/smb3 message checking code was logging to dmesg when mounting
> with encryption ("seal") for compounded SMB3 requests.  When encrypted
> the whole frame (including potentially multiple compounds) is read
> so the length field is longer than in the case of non-encrypted
> case (where length field will match the the calculated length for
> the particular SMB3 request in the compound being validated).
>
> Avoids the warning on mount (with "seal"):
>
>    "srv rsp padded more than expected. Length 384 not ..."
>
> --
> Thanks,
>
> Steve



-- 
Thanks,

Steve

[-- Attachment #2: 0001-smb3-remove-confusing-dmesg-when-mounting-with-encry.patch --]
[-- Type: text/x-patch, Size: 1835 bytes --]

From 0ad92ed9bf9cd9e4bc9412d3f6e9ccbfcc27fb43 Mon Sep 17 00:00:00 2001
From: Steve French <stfrench@microsoft.com>
Date: Fri, 8 Nov 2019 01:01:35 -0600
Subject: [PATCH 1/2] smb3: remove confusing dmesg when mounting with
 encryption ("seal")

The smb2/smb3 message checking code was logging to dmesg when mounting
with encryption ("seal") for compounded SMB3 requests.  When encrypted
the whole frame (including potentially multiple compounds) is read
so the length field is longer than in the case of non-encrypted
case (where length field will match the the calculated length for
the particular SMB3 request in the compound being validated).

Avoids the warning on mount (with "seal"):

   "srv rsp padded more than expected. Length 384 not ..."

Signed-off-by: Steve French <stfrench@microsoft.com>
---
 fs/cifs/smb2misc.c | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/fs/cifs/smb2misc.c b/fs/cifs/smb2misc.c
index 4b7ff3d1e830..a524fc1fad84 100644
--- a/fs/cifs/smb2misc.c
+++ b/fs/cifs/smb2misc.c
@@ -250,16 +250,10 @@ smb2_check_message(char *buf, unsigned int len, struct TCP_Server_Info *srvr)
 		 * of junk. Other servers match RFC1001 len to actual
 		 * SMB2/SMB3 frame length (header + smb2 response specific data)
 		 * Some windows servers also pad up to 8 bytes when compounding.
-		 * If pad is longer than eight bytes, log the server behavior
-		 * (once), since may indicate a problem but allow it and continue
-		 * since the frame is parseable.
 		 */
-		if (clc_len < len) {
-			pr_warn_once(
-			     "srv rsp padded more than expected. Length %d not %d for cmd:%d mid:%llu\n",
-			     len, clc_len, command, mid);
+		if (clc_len < len)
 			return 0;
-		}
+
 		pr_warn_once(
 			"srv rsp too short, len %d not %d. cmd:%d mid:%llu\n",
 			len, clc_len, command, mid);
-- 
2.23.0


      reply	other threads:[~2019-11-08  7:08 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-05 22:47 [PATCH][SMB3] remove confusing dmesg when mounting with encryption Steve French
2019-11-08  7:07 ` Steve French [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH2r5mtZhTx2nX1aTrMfBXY=QZKars-P8MzsnxAA1-EARKZddg@mail.gmail.com' \
    --to=smfrench@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=piastryyy@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).