Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #91402 > unrolled thread

Bug#1128397: linux-image-6.18.10+deb14-amd64: open(/proc/$pid/maps) is empty after $pid exec()s, unless you read a partial line from the fd before, in which case it has the rest of the line only

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1128397: linux-image-6.18.10+deb14-amd64: open(/proc/$pid/maps) is empty after $pid exec()s, unless you read a partial line from the fd before, in which case it has the rest of the line only Ben Hutchings <ben@decadent.org.uk> - 2026-02-25 20:30 +0100
    Bug#1128397: linux-image-6.18.10+deb14-amd64: open(/proc/$pid/maps) is empty after $pid exec()s, unless you read a partial line from the fd before, in which case it has the rest of the line only наб <nabijaczleweli@nabijaczleweli.xyz> - 2026-02-25 23:40 +0100

#91402 — Bug#1128397: linux-image-6.18.10+deb14-amd64: open(/proc/$pid/maps) is empty after $pid exec()s, unless you read a partial line from the fd before, in which case it has the rest of the line only

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 moreinfo

Opening /proc/$pid/maps gives you a representation of the current memory
space of $pid.  execve() tears down that memory space and creates a new
memory space.  The open file is left referring to the old memory space,
which is now empty (but won't be freed as long as the file is open).  I
think it's correct that no more mappings are visible through the open
file at this point.

What are you proposing would be the correct behaviour?

Ben.

-- 
Ben Hutchings
Anthony's Law of Force: Don't force it, get a larger hammer.

[toc] | [next] | [standalone]

#91412

[Multipart message — attachments visible in raw view] — view raw

Control: tags -1 - moreinfo

I'll be honest with you, I don't really know.

Locking in the memory map on read() instead of on open() seems at least
as bad if not worse.

For read -> exec -> read, the second read yielding the partial
"b3000 r--p 00000000 00:8a 816985                     /home/nabijaczleweli/uwu/otp/a.out\n"
isn't pretty, but the alternative is that you get your line truncated
for no reason if your buffer falls mid-line,
which does now sound worse than keeping that as-is.

Of course, the seek behaviour seems obviously wrong as well:
  lseek(0, 200, SET) reads empty,
  lseek(0, 220, SET) reads the first line skip 20 characters,
  lseek(0, 201, SET) reads the first line skip 1 character,
  lseek(0, 110, SET) reads the first line skip 10 characters:
  (yes, the hundred digit seems meaningless here? 6.1.0-35-amd64)
  int main() {
  	close(0);
  	open("/proc/self/maps", 0);
  	lseek(0, (long)110, 0);
  	execlp("cat", "cat", (void *)0);
  }
but that seems tangential.

Best,

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web