public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ZhengYuan Huang <gality369@gmail.com>
To: viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	baijiaju@buaa.edu.cn
Subject: [BUG] fs/eventfd: Possible undefined behavior about read and eventfd interaction
Date: Wed, 20 Nov 2024 13:40:32 +0800	[thread overview]
Message-ID: <0c04e4ea-b900-4476-abc9-6b57e5c26e43@gmail.com> (raw)

Hello,

Our dynamic analysis tool has encountered a potential issue with the
interaction between read and eventfd. Below is a minimal code snippet
to reproduce the behavior:

int main() {
  int fd = syscall(__NR_eventfd, 1);
  int ret = syscall(__NR_read, fd, 0x000fffffffffffff, 8);
  assert(ret == -1); // invalid address
  long value;
  int ret2 = syscall(__NR_read, fd, &value, 8);
  assert(0); // never reached here
  return 0;
}

When read is called with an eventfd file descriptor and an invalid 
address as the second argument, it fails and correctly returns an 
"invalid address" error. However, the second read syscall does not 
proceed; instead, it blocks indefinitely. This suggests that the 
counter in the eventfd object is consumed by the first read syscall, 
despite its failure.

I could not find any explanation for this behavior in the man pages 
or the source code. Could you clarify if this behavior is expected, 
or might it be a bug?

Thank you for your time and assistance. Please let me know if 
further details or additional reproducer information are needed.

Best wishes,
ZhengYuan Huang

             reply	other threads:[~2024-11-20  5:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-20  5:40 ZhengYuan Huang [this message]
2024-11-20 10:26 ` [BUG] fs/eventfd: Possible undefined behavior about read and eventfd interaction Christian Brauner

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=0c04e4ea-b900-4476-abc9-6b57e5c26e43@gmail.com \
    --to=gality369@gmail.com \
    --cc=baijiaju@buaa.edu.cn \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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