xfsprogs: check for size parsing errors in xfs_quota

Doing something like

# xfs_quota -x -c 'limit -u bhard=1.2g ...

will cause cvtnum to fail and return a value of -1LL (because it cannot parse the decimal), but the quota caller doesn't check for this error value, casts it to U64, shifts right, and we end up with an answer of 16 petabytes rather than erroring out. Fix this.

Quoted 4 lines · Eric Sandeen

Doing something like

# xfs_quota -x -c 'limit -u bhard=1.2g ...

Quoted 5 lines

will cause cvtnum to fail and return a value of -1LL (because it cannot parse the decimal), but the quota caller doesn't check for this error value, casts it to U64, shifts right, and we end up with an answer of 16 petabytes rather than erroring out. Fix this.

Can you add a test case for it, please?

quota/edit.c extractb( · line 239

Quoted 8 lines

quota/edit.c +6 -2

-		v = (__uint64_t)cvtnum(blocksize, sectorsize, s);
-		*value = v >> 9;	/* syscalls use basic blocks */
+		v = cvtnum(blocksize, sectorsize, s);
+		if (v == -1LL) {
+			fprintf(stderr, _("%s: Error: could not parse size %s.\n"), progname, s);
+			return 0;
+		}
+		*value = (__uint64_t)v >> 8;	/* syscalls use basic blocks */

Why do you replace the shift by nine with a shift by 8?

Also please don't introduce new overly long lines, just move the translated string to a line of its own, indented by a single tab similar to how we do it in most new xfs/xfsprogs code.

Doing something like

# xfs_quota -x -c 'limit -u bhard=1.2g ...

will cause cvtnum to fail and return a value of -1LL (because it cannot parse the decimal), but the quota caller doesn't check for this error value, casts it to U64, shifts right, and we end up with an answer of 16 petabytes rather than erroring out. Fix this.

Reported-by James Lawrie<[email protected]>

Signed-off-by Eric Sandeen<[email protected]>

---