GopherProxy

	sfeed_curses: fix (very hard to trigger) memleak when getline() returns EOF for…
	git clone git://git.codemadness.org/sfeed
	Log
	Files
	Refs
	README
	LICENSE
	---
	commit 426fa33dd276fbe662b3794c41db1ab6d59b3c2a
	parent 19a4c010f95ad17e02ca59e9949524e801ad22f2
	Author: Hiltjo Posthuma <[email protected]>
	Date: Tue, 7 Mar 2023 21:04:36 +0100

	sfeed_curses: fix (very hard to trigger) memleak when getline() returns EOF for…

	Fix the code pattern of freeing the line when getline returns -1 but no error
	flag is set on the stream (such as EOF).

	Note that on errors (even ENOMEM: out-of-memory) an error flag is set on the
	stream and the process would exit and clean up all it's resources.

	This would be very hard to trigger. The following conditions would have to be
	true:

	* Lazyloading of items is enabled: SFEED_LAZYLOAD=1 is set.
	* Items of the feed are read and their offsets stored.
	* The line is read/lazy-loaded again by it's offset but returns EOF (not a read
	error) this time.
	This could maybe happen if the feed file was changed and made smaller while
	sfeed_curses is running and the remembered offset is now beyond the file.

	Note that the sfeed_curses(1) man page describes a workaround for a similar
	condition by sending SIGHUP if the sfeed(5) data was changed to reload the fe…
	file.

	References:
	* https://man.openbsd.org/getline
	"It is the responsibility of the caller to free(3) *lineptr when it is no
	longer needed. Even when it fails, getdelim() may update *lineptr."
	* https://pubs.opengroup.org/onlinepubs/9699919799/functions/getline.html

	Diffstat:
	M sfeed_curses.c \| 1 +

	1 file changed, 1 insertion(+), 0 deletions(-)
	---
	diff --git a/sfeed_curses.c b/sfeed_curses.c
	@@ -1791,6 +1791,7 @@ item_row_get(struct pane *p, off_t pos)
	if ((linelen = getline(&line, &linesize, f->fp)) <= 0) {
	if (ferror(f->fp))
	die("getline: %s", f->path);
	+ free(line);
	return NULL;
	}