[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1897: apropos not resilient to index.db corruption



Package: man
Version: 2.3.10-2

'man -k' and 'apropos' with a damaged or corrupted index.db
segfaults.  This is not a very friendly error message.

I have traced the problem to the following piece of code:

------------------------ whatis.c ------------------------------------
364: /* scan for the page, print any matches */
365: static int apropos(char *page, char *lowpage)
366: {
367: 	datum key, cont;
368: 	int found = 0;
369:
370: #ifndef BTREE
371: 	datum nextkey;
372:
373: 	key = MYDBM_FIRSTKEY(dbf);
374: 	while (key.dptr) {
375: 		if (*key.dptr != '$') {
376: 			cont= MYDBM_FETCH(dbf, key);
377: #else /* BTREE */
378: 	int end;
379:
380: 	end = btree_nextkeydata(dbf, &key, &cont);
381: 	while (!end) {
382: 		if (*key.dptr != '$') {
383: #endif /* !BTREE */
384: 			if (*cont.dptr != '\t') {	/* a real page */
----------------------------------------------------------------------

If the database is corrupted, then it is possible to read off the end
of the database without seeing a '$' (line 375), and calling
MYDBM_FETCH() when there isn't any data to fetch.  This makes 'cont'
NULL (line 376), which gets dereferenced in line 384. Kaboom,
segfault.

Could this infelicity be passed on to the upstream maintainer, please
?

The problem with just checking for null is that this is very likely
not the only place where things can go wrong.

Also, it might be nice to have a database consistancy checker, that
would tell you if a given database were consistant.

Austin


Reply to: