linux-kernel - [BUG] fs/eventfd: Possible undefined behavior about read and eventfd interaction

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: <0c04e4ea-b900-4476-abc9-6b57e5c26e43@gmail.com>
Date: Wed, 20 Nov 2024 13:40:32 +0800
From: ZhengYuan Huang <gality369@...il.com>
To: viro@...iv.linux.org.uk, brauner@...nel.org, jack@...e.cz
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
 baijiaju@...a.edu.cn
Subject: [BUG] fs/eventfd: Possible undefined behavior about read and eventfd
 interaction

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