Bug 1622167

Summary: Fix potential divide-by-zero in sunrpc reserved port range calculation
Product: Red Hat Enterprise Linux 7 Reporter: Frank Sorenson <fsorenso>
Component: kernelAssignee: Steve Dickson <steved>
kernel sub component: NFS QA Contact: JianHong Yin <jiyin>
Status: CLOSED ERRATA Docs Contact:
Severity: unspecified    
Priority: high CC: bcodding, rhandlin, steved, swhiteho, xzhou, yoyang
Version: 7.5   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: kernel-3.10.0-983.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-06 12:09:10 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:

Description Frank Sorenson 2018-08-24 14:58:57 UTC
Description of problem:

A bug in the reserved port range calculation can cause a divide-by-zero system panic when the min_resvport and max_resvport are equal.

Also, min_resvport can be set to a value higher than max_resvport (and vice versa), leading to a similar panic even when the initial bug is fixed.

Backport the 3 patches which resolve these issues.


Version-Release number of selected component (if applicable):

all RHEL kernels


How reproducible:

easy

Steps to Reproduce:


# sysctl sunrpc.max_resvport=800 sunrpc.min_resvport=800
# mount server:/export /mnt/tmp


Actual results:

kernel panic


Expected results:

reserved port calculation chooses the specified port, with no panic


Additional info:

the bug in port calculation incorrectly treats min_resvport==max_resvport as having 0 approved ports, while in reality one port fits the requirement:

    min_resvport <= <chosen_port> <= max_resvport

with min_resvport==max_resvport, that port itself should be accepted.


The following 3 upstream patches (also sent to -stable) resolve this bug, as well as prevent specification of incorrect values for min_resvport and max_resvport which could still lead to a divide-by-zero even when fixed:

commit 5d71899a26630654d65e143c63c3c6f12d9aa287
Author: Frank Sorenson <sorenson>
Date:   2016-07-08 16:35:23 -0500

    sunrpc: Fix reserved port range calculation
    
    The range calculation for choosing the random reserved port will panic
    with divide-by-zero when min_resvport == max_resvport, a range of one
    port, not zero.
    
    Fix the reserved port range calculation by adding one to the difference.
    
    Signed-off-by: Frank Sorenson <sorenson>
    Signed-off-by: Trond Myklebust <trond.myklebust>


commit e08ea3a96fc7112921023b77b737098690a666dc
Author: Frank Sorenson <sorenson>
Date:   2016-07-08 16:35:24 -0500

    sunrpc: Prevent resvport min/max inversion via sysctl
    
    The current min/max resvport settings are independently limited
    by the entire range of allowed ports, so max_resvport can be
    set to a port lower than min_resvport.
    
    Prevent inversion of min/max values when set through sysctl by
    setting the limits dependent on each other.
    
    Signed-off-by: Frank Sorenson <sorenson>
    Signed-off-by: Trond Myklebust <trond.myklebust>


commit ffb6ca33b04b965ac7dd10676537b93e2476dcec
Author: Frank Sorenson <sorenson>
Date:   2016-07-08 16:35:25 -0500

    sunrpc: Prevent resvport min/max inversion via sysfs and module parameter
    
    The current min/max resvport settings are independently limited
    by the entire range of allowed ports, so max_resvport can be
    set to a port lower than min_resvport.
    
    Prevent inversion of min/max values when set through sysfs and
    module parameter by setting the limits dependent on each other.
    
    Signed-off-by: Frank Sorenson <sorenson>
    Signed-off-by: Trond Myklebust <trond.myklebust>

Comment 2 Murphy Zhou 2018-08-25 02:01:27 UTC
Looks straight forward and it's a panic issue.

Propose blocker to get in RHEL-7.6.

Comment 6 Steve Whitehouse 2018-10-09 12:39:12 UTC
Looks like it has been posted, but missing ACKs at the moment

Comment 9 Bruno Meneguele 2018-12-19 13:31:20 UTC
Patch(es) committed on kernel-3.10.0-983.el7

Comment 12 JianHong Yin 2019-01-22 06:31:09 UTC
verified on RHEL-7.7(kernel-3.10.0-993.el7)
 https://beaker.engineering.redhat.com/jobs/3301104

reproduced on RHEL-7.6(kernel-3.10.0-957.el7):
 https://beaker.engineering.redhat.com/jobs/3301103
'''
[  124.623829] divide error: 0000 [#1] SMP  
[  124.624721] Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache nfsd auth_rpcgss nfs_acl lockd grace sunrpc intel_powerclamp coretemp ipmi_ssif kvm_intel kvm iTCO_wdt iTCO_vendor_support irqbypass cdc_ether usbnet ipmi_si mii sg i2c_i801 ipmi_devintf pcspkr ipmi_msghandler ioatdma lpc_ich i7core_edac dca acpi_cpufreq ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic crct10dif_common mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt ata_generic pata_acpi fb_sys_fops ttm drm ata_piix crc32c_intel serio_raw mptsas scsi_transport_sas libata mptscsih drm_panel_orientation_quirks mptbase bnx2 dm_mirror dm_region_hash dm_log dm_mod 
[  124.624721] CPU: 7 PID: 10335 Comm: kworker/7:1H Kdump: loaded Not tainted 3.10.0-957.el7.x86_64 #1 
[  124.624721] Hardware name: IBM System x3550 M3 -[7944I21]-/69Y4438     , BIOS -[D6E148BUS-1.08]- 06/25/2010 
[  124.624721] Workqueue: xprtiod xs_tcp_setup_socket [sunrpc] 
[  124.624721] task: ffff8dbd71a0d140 ti: ffff8dbd6e2ac000 task.ti: ffff8dbd6e2ac000 
[  124.624721] RIP: 0010:[<ffffffffc07d6086>]  [<ffffffffc07d6086>] xs_bind+0x186/0x270 [sunrpc] 
[  124.624721] RSP: 0018:ffff8dbd6e2afcd0  EFLAGS: 00010246 
[  124.624721] RAX: 000000004b65fcf9 RBX: ffff8dbd6e633800 RCX: 00000000e06e15f2 
[  124.624721] RDX: 0000000000000000 RSI: 00000000d2f87a9c RDI: ffff8dbd7fad83b0 
[  124.624721] RBP: ffff8dbd6e2afd80 R08: 000000000b400000 R09: ffff8dbbfcf39400 
[  124.624721] R10: ffffffffb9119206 R11: 0000000000000000 R12: 0000000000000000 
[  124.624721] R13: 0000000000000000 R14: 0000000000000001 R15: ffff8dbbfcf39400 
[  124.624721] FS:  0000000000000000(0000) GS:ffff8dbd7fac0000(0000) knlGS:0000000000000000 
[  124.624721] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 
[  124.624721] CR2: 00007f0ccccf81a0 CR3: 000000044f764000 CR4: 00000000000207e0 
[  124.624721] Call Trace: 
[  124.624721]  [<ffffffffb941e980>] ? release_sock+0x120/0x170 
[  124.624721]  [<ffffffffb9420838>] ? sock_setsockopt+0x1b8/0x8d0 
[  124.624721]  [<ffffffffb90f97fc>] ? security_socket_post_create+0x1c/0x20 
[  124.624721]  [<ffffffffc07d61c9>] xs_create_sock.isra.18+0x59/0xe0 [sunrpc] 
[  124.624721]  [<ffffffffc07d78bf>] xs_tcp_setup_socket+0x26f/0x490 [sunrpc] 
[  124.820101]  [<ffffffffb8eb9d4f>] process_one_work+0x17f/0x440 
[  124.820101]  [<ffffffffb8ebade6>] worker_thread+0x126/0x3c0 
[  124.820101]  [<ffffffffb8ebacc0>] ? manage_workers.isra.25+0x2a0/0x2a0 
[  124.820101]  [<ffffffffb8ec1c31>] kthread+0xd1/0xe0 
[  124.820101]  [<ffffffffb8ec1b60>] ? insert_kthread_work+0x40/0x40 
[  124.820101]  [<ffffffffb9574c37>] ret_from_fork_nospec_begin+0x21/0x21 
[  124.820101]  [<ffffffffb8ec1b60>] ? insert_kthread_work+0x40/0x40 
[  124.820101] Code: 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 1f 84 00 00 00 00 00 44 8b 2d 5d d7 02 00 66 44 2b 2d 59 d7 02 00 e8 cc 1d 9b f8 31 d2 <66> 41 f7 f5 66 03 15 47 d7 02 00 41 89 d4 74 ab e9 a5 fe ff ff  
[  124.820101] RIP  [<ffffffffc07d6086>] xs_bind+0x186/0x270 [sunrpc] 
[  124.820101]  RSP <ffff8dbd6e2afcd0> 
'''

Comment 14 errata-xmlrpc 2019-08-06 12:09:10 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/RHSA-2019:2029