public inbox for linux-cifs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Aurélien Aptel" <aaptel@suse.com>
To: Seth Thielemann <sthielemann@barracuda.com>,
	CIFS <linux-cifs@vger.kernel.org>
Subject: Re: [PATCH cifs segfault ]
Date: Tue, 06 Apr 2021 16:28:14 +0200	[thread overview]
Message-ID: <87eefn4hdt.fsf@suse.com> (raw)
In-Reply-To: <DM6PR10MB3833F0DD867BF1B48F60B99FA2769@DM6PR10MB3833.namprd10.prod.outlook.com>

Hi Seth,

Seth Thielemann <sthielemann@barracuda.com> writes:
> - Observed segfaults during cifs share backups, core investigation and strace revealed that files were being opened
>   but upon read the syscall was returning a 32-bit error code:

On my system (x86_64)
- ssize_t is signed and long which is 8 bytes
- int is signed and 4 bytes

That is a weird bug. Casting (long)-13 to int is ok because -13 is
representable in both.

> - Above is an impossible situation, the sign extension was at fault. The two functions using the trinary assignment of rc
> in the cifs asio context:

You mean this line in collect_uncached_write_data() right? I think the
current code changed from your version, it's in a different function now.

	ctx->rc = (rc == 0) ? ctx->total_len : rc;

>    188db:       45 85 e4                test   r12d,r12d

Ok I'm assuming r12d is the rc var.
we test if rc == 0 (low 32bit of r12)

>    188de:       44 89 e0                mov    eax,r12d   <- msl cleared

Now we set eax (low 32bits) to rc (what is msl? most significat l...?).
But the high 32bits are unknown

>    188e1:       0f 84 6a 01 00 00       je     18a51 <cifs_uncached_writev_complete+0x371>

if rc was zero, we take the jump

>    188e7:       48 8b 7c 24 18          mov    rdi,QWORD PTR [rsp+0x18]
>    188ec:       49 89 85 a8 00 00 00    mov    QWORD PTR [r13+0xa8],rax <- saved

Otherwise we store rax (unknown high 32 bits + low 32bit of rc) in the ctx.

So -13 is

    0xfffffff3 (int)

but if you copy it in low part of a zero 64bits you end up with (wrong)

    0x00000000fffffff3 (long)
    
which is 4294967283... should have been 0xfffffffffffffff3

I'm no compiler expert but this looks like possible wrong generated
code for the cast :/

Cheers,
-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München)


  reply	other threads:[~2021-04-06 14:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-06 12:17 [PATCH cifs segfault ] Seth Thielemann
2021-04-06 14:28 ` Aurélien Aptel [this message]
2021-04-06 16:35   ` Seth Thielemann
2021-04-07 14:16     ` Aurélien Aptel
2021-04-09  4:18       ` Steve French

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=87eefn4hdt.fsf@suse.com \
    --to=aaptel@suse.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=sthielemann@barracuda.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