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

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

[ZhengYuan Huang]

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

Re: [BUG] fs/eventfd: Possible undefined behavior about read and eventfd interaction

[Christian Brauner]

On Wed, Nov 20, 2024 at 01:40:32PM +0800, ZhengYuan Huang wrote:
> 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.

Yes, that is expected as the copy_to_user() is the last step in
eventfd_read() and userspace clearly messed up by providing an invalid
address.