[Bug 1861776] [NEW] fseek(…, …, SEEK_SET) causes reading over the skipped range

[Konstantin]

Public bug reported:

When fseek is called, it calls in turn 1. lseek(), and 2. read(). In
glibc 2.30 (maybe earlier) read() is only called for the last block.
However in glibc 2.27 Ubuntu 18.04 is using, the read happens over the
whole skipped range, which may cause a hang of an app that tries to skip
too big range.

There's is a related report:
https://sourceware.org/bugzilla/show_bug.cgi?id=25497 Note, per
comments, in at least glibc 2.30 read() only happens for the *last
block*. This means there was some fix for fseek() to not read over
everything it skipped, which Ubuntu didn't backport to older glibc it's
using.

# Steps to reproduce

In command below, replace `/dev/sda` if necessary with a device that is
at least 2 GB in size.

Run `sudo hexdump -C /dev/sda -s 0x80000000 -n 1`. This command uses
`hexdump` to print content of a disk at a large offset.

## Expected

The command returns immediately with a print

## Actual

The command hangs with high CPU load. If you use `strace hexdump …`,
you'll see there a bunch of reads happens. These reads arise from glibc
2.27 implementation of `fseek()`.

** Affects: glibc (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/1861776

Title:
  fseek(…, …, SEEK_SET) causes reading over the skipped range

Status in glibc package in Ubuntu:
  New

Bug description:
  When fseek is called, it calls in turn 1. lseek(), and 2. read(). In
  glibc 2.30 (maybe earlier) read() is only called for the last block.
  However in glibc 2.27 Ubuntu 18.04 is using, the read happens over the
  whole skipped range, which may cause a hang of an app that tries to
  skip too big range.

  There's is a related report:
  https://sourceware.org/bugzilla/show_bug.cgi?id=25497 Note, per
  comments, in at least glibc 2.30 read() only happens for the *last
  block*. This means there was some fix for fseek() to not read over
  everything it skipped, which Ubuntu didn't backport to older glibc
  it's using.

  # Steps to reproduce

  In command below, replace `/dev/sda` if necessary with a device that
  is at least 2 GB in size.

  Run `sudo hexdump -C /dev/sda -s 0x80000000 -n 1`. This command uses
  `hexdump` to print content of a disk at a large offset.

  ## Expected

  The command returns immediately with a print

  ## Actual

  The command hangs with high CPU load. If you use `strace hexdump …`,
  you'll see there a bunch of reads happens. These reads arise from
  glibc 2.27 implementation of `fseek()`.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1861776/+subscriptions