Bug 1517822

Summary: Big quota values overflow when reading them from kernel
Product: Red Hat Enterprise Linux 7 Reporter: Petr Pisar <ppisar>
Component: quotaAssignee: Petr Pisar <ppisar>
Status: CLOSED ERRATA QA Contact: Robin Hack <rhack>
Severity: medium Docs Contact:
Priority: low    
Version: 7.4CC: adas, emajorsi, jorton, lmiksik, psklenar, rhack, swhiteho
Target Milestone: rcKeywords: Patch, Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://sourceforge.net/p/linuxquota/bugs/113/
Whiteboard:
Fixed In Version: quota-4.01-17.el7 Doc Type: No Doc Update
Doc Text:
undefined
Story Points: ---
Clone Of: 1009397 Environment:
Last Closed: 2018-04-10 08:42:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
1st upstream patch
none
2nd upstream fix none

Description Petr Pisar 2017-11-27 14:36:17 UTC
+++ This bug was initially created as a clone of Bug #1009397 +++
[...]
--- Additional comment from Petr Pisar on 2013-09-18 10:47:15 GMT ---

The rpc.rquotad is addressed in bug #1007785.

This bug report is about quota tools accepting big values from kernel which then overflow due to internal representation in quota tools.

Example:

$ quota -vs
Disk quotas for user test (uid 500): 
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
     /dev/loop0 18446744073709551612       0       0               0       0       0        
localhost:/quota
                  4096G       0       0               0       0       0        

Here you can see /dev/loop0 block usage was not abbreviated and that the same field reported over RPC (localhost:/quota) mismatches. This is due to the overflow to negative values and comparison against 0 and printing as unsigned value. This is still problem in the upstream version.

--- Additional comment from Petr Pisar on 2014-10-21 13:00:30 GMT ---

Upstream concluded kernel uses signed values internally, so user space should too. (Because used size can go into negative values on not synchronized cluster nodes. So the unsigned kernel interface is a mistake and user space should interpret the values as signed.)

Upstream fixed this issue by changing quota tools printing int input layer to consider the values as signed with these two commits:


commit 0214512479e04a3e118cbef8703aa1aec5240f3f
Author: Jan Kara <jack>
Date:   Thu May 1 18:08:09 2014 +0200

    Properly handle signed space and inode values
    
    For cluster filesystems, kernel can sometimes return negative values of
    used space or inodes (because counters are not completely synchronized
    across the cluster). Make quota tools properly print these.
    
    Signed-off-by: Jan Kara <jack>

commit 663ac451b045b4823d6d633893a5d748c09f42f2
Author: Jan Kara <jack>
Date:   Wed Oct 1 18:10:40 2014 +0200

    Fix handling of space and inode values
    
    Commit 0214512479e0 (Properly handle signed space and inode values)
    broke parsing of pure numbers in str2number() so that it would always
    complain about "Integer overflow while interpreting decimal unit". Fix
    condition checking for overflow.
    
    Also number2str() was buggy and wouldn't guess proper units for negative
    numbers.
    
    Signed-off-by: Jan Kara <jack>

--- Additional comment from Petr Pisar on 2015-01-06 13:21:54 GMT ---

How to test:
(1) Mount GFS2 file system with negative quota usage values. (You can use attachment #799336 [details] "GFS2 image with big block usage value for UID 500" from
bug #1007785.)
(2) List quotas for UID 500 by repoqota tool.
Before: Block usage is 18446744073709551612.
After: Block usage is -4.

---

RHEL-7 (quota-4.01-16.el7) is affected too.

Comment 2 Petr Pisar 2017-11-27 15:23:07 UTC
Created attachment 1359514 [details]
1st upstream patch

Comment 3 Petr Pisar 2017-11-27 15:23:46 UTC
Created attachment 1359518 [details]
2nd upstream fix

Comment 11 errata-xmlrpc 2018-04-10 08:42:52 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:0667