RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1841456 - automount program crashes with "malloc(): invalid next size (unsorted)"
Summary: automount program crashes with "malloc(): invalid next size (unsorted)"
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: autofs
Version: 8.2
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: 8.0
Assignee: Ian Kent
QA Contact: Kun Wang
URL:
Whiteboard:
Depends On:
Blocks: 1847762
TreeView+ depends on / blocked
 
Reported: 2020-05-29 07:54 UTC by Achilles Gaikwad
Modified: 2023-12-15 18:01 UTC (History)
2 users (show)

Fixed In Version: autofs-5.1.4-43
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1847762 (view as bug list)
Environment:
Last Closed: 2020-11-04 02:06:04 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
coredumps of autofs from my test lab environment (959.38 KB, application/gzip)
2020-06-01 07:45 UTC, Achilles Gaikwad 		no flags Details
Patch - initialize struct addrinfo for getaddrinfo() calls (3.10 KB, patch)
2020-06-02 05:36 UTC, Ian Kent 		no flags Details | Diff
Patch - fix quoted string length calc in expandsunent() (1.29 KB, patch)
2020-06-02 05:37 UTC, Ian Kent 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:4573 0 None None None 2020-11-04 02:06:08 UTC

Comment 3 Ian Kent 2020-05-30 05:19:05 UTC 
Looking at the case I see it looks like there's a string length calculation
problem too. That could well be the cause of both problems.

I'd like to look at the core as well.

It's difficult to setup a system to do that properly, even when using the
info. we get from an sosreport, which must come from the system the core
was taken on or a system with the same hardware and RHEL release with
identical updates installed.

Can I get an sosreport from the customer please.

Ian
Comment 4 Ian Kent 2020-05-30 13:00:45 UTC 
(In reply to Ian Kent from comment #3)
> 
> Can I get an sosreport from the customer please.
> 

Never mind I was able to reproduce both symptoms on 8.2 at different locations.

I can't see any mistakes in the surrounding code after extracting parts of the
code and checking functionality with the strings involved. valgrind doesn't
show anything either.

I'll check further.

Ian
Comment 5 Achilles Gaikwad 2020-06-01 07:37:34 UTC 
Hello Ian,

I hope you're doing well! 

Thank you for looking into this bug report. I really appreciate your help!

I tried reproducing the issue so that I could get `malloc(): corrupted top size` instead got different errors in malloc. 

Below are the list of items that I faced. Please do read the Observations section below. There may be some important pointers there to conclude what's causing this issue.

[0x1] Captured from my local reproducer on RHEL 8 system with autofs-5.1.4-40.el8.x86_64.
=====
Error   : automount: malloc.c:2396: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.
Filename: E.coredump

Initial investigation:
~~~
:::
#16 0x00007fa045fd2eea in mount_mount (ap=0x55bd38311060, root=0x55bd38311000 "/mnt/home",
    name=0x7fa044b79230 "0123456789100", name_len=13,
    what=0x7fa044b791f0 "vm137.gsslab.pnq.redhat.com:/exports/012345678910e",
    fstype=<optimized out>,
    options=0x7fa044b79260 "rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0",
    context=0x0) at mount_nfs.c:215
#17 0x00007fa04620c35d in sun_mount (ap=ap@entry=0x55bd38311060, root=<optimized out>,
    name=<optimized out>, namelen=<optimized out>, loc=<optimized out>, loclen=<optimized out>,
    options=0x7fa044b79260 "rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0",
    ctxt=<optimized out>) at parse_sun.c:691
#18 0x00007fa04620e444 in parse_mount (ap=0x55bd38311060, name=0x7fa044b79690 "0123456789100",
    name_len=13, mapent=<optimized out>, context=<optimized out>) at parse_sun.c:1735
#19 0x00007fa046443588 in lookup_mount (ap=0x55bd38311060, name=<optimized out>,
    name_len=<optimized out>, context=0x7fa03c000d70) at lookup_file.c:1306
#20 0x000055bd37a9a6d1 in do_lookup_mount (ap=ap@entry=0x55bd38311060, map=0x7fa03c000c10,
    name=name@entry=0x7fa044b7dc90 "0123456789100", name_len=name_len@entry=13) at lookup.c:833
#21 0x000055bd37a9ab0f in lookup_name_file_source_instance (ap=ap@entry=0x55bd38311060,
    map=map@entry=0x55bd38311360, name=name@entry=0x7fa044b7dc90 "0123456789100",
    name_len=name_len@entry=13) at lookup.c:974
#22 0x000055bd37a9b44c in lookup_nss_mount (ap=ap@entry=0x55bd38311060, source=source@entry=0x0,
    name=name@entry=0x7fa044b7dc90 "0123456789100", name_len=13) at lookup.c:1216
#23 0x000055bd37a91c18 in do_mount_indirect (arg=<optimized out>) at indirect.c:754
#24 0x00007fa04b2252de in start_thread (arg=<optimized out>) at pthread_create.c:486
#25 0x00007fa049892e83 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
~~~

Observations: 
    notice that I requested for a mount of  0123456789100, but somewhere down the stack the value
    got changed to 012345678910e.
    I do not know yet where the "e" came from.

[0x2] Attaching the file named quoted.coredump
=====
Error   : malloc(): invalid next size (unsorted)
Filename: quoted.coredump
Initial investigation:
~~~
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f5134639b25 in __GI_abort () at abort.c:79
#2  0x00007f5134692897 in __libc_message (action=action@entry=do_abort,
    fmt=fmt@entry=0x7f513479f057 "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007f5134698fdc in malloc_printerr (
    str=str@entry=0x7f51347a1120 "malloc(): invalid next size (unsorted)") at malloc.c:5366
#4  0x00007f513469bebc in _int_malloc (av=av@entry=0x7f5110000020, bytes=bytes@entry=83)
    at malloc.c:3751
#5  0x00007f513469d662 in __GI___libc_malloc (bytes=bytes@entry=83) at malloc.c:3073
#6  0x00005599ff02d071 in dequote (
    str=str@entry=0x7f5110001581 "fstype=nfs,rw,nosuid,soft,nfsvers=3,context=\"system_u:object_r:user_home_dir_t:s0\"    vm137.gsslab.pnq.redhat.com:/exports/0123456789100", origlen=origlen@entry=82,
    logopt=logopt@entry=0) at parse_subs.c:719
#7  0x00007f513108eeb1 in parse_options (logopt=0, ret=<synthetic pointer>,
    str=0x7f5110001580 "-fstype=nfs,rw,nosuid,soft,nfsvers=3,context=\"system_u:object_r:user_home_dir_t:s0\"    vm137.gsslab.pnq.redhat.com:/exports/0123456789100") at parse_sun.c:470
#8  parse_mount (ap=0x5599ffa73140, name=0x7f512b7f7690 "0123456789100", name_len=13,
    mapent=<optimized out>, context=0x7f5120000b80) at parse_sun.c:1368
#9  0x00007f51312c4588 in lookup_mount (ap=0x5599ffa73140, name=<optimized out>,
    name_len=<optimized out>, context=0x7f5120000d70) at lookup_file.c:1306
#10 0x00005599ff0156d1 in do_lookup_mount (ap=ap@entry=0x5599ffa73140, map=0x7f5120000c10,
    name=name@entry=0x7f512b7fbc90 "0123456789100", name_len=name_len@entry=13) at lookup.c:833
#11 0x00005599ff015b0f in lookup_name_file_source_instance (ap=ap@entry=0x5599ffa73140,
    map=map@entry=0x5599ffa73440, name=name@entry=0x7f512b7fbc90 "0123456789100",
    name_len=name_len@entry=13) at lookup.c:974
#12 0x00005599ff01644c in lookup_nss_mount (ap=ap@entry=0x5599ffa73140, source=source@entry=0x0,
    name=name@entry=0x7f512b7fbc90 "0123456789100", name_len=13) at lookup.c:1216
#13 0x00005599ff00cc18 in do_mount_indirect (arg=<optimized out>) at indirect.c:754
#14 0x00007f51360a62de in start_thread (arg=<optimized out>) at pthread_create.c:486
#15 0x00007f5134713e83 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
~~~
Observations: 
    Notice that the context is quoted in #6.
    The issue either doesn't occur or is difficult to reproduce without the quotes.

[0x3]
===== 
Error   : malloc(): mismatching next->prev_size (unsorted)
Filename: mismatch.coredump
Initial investigation:

~~~
(gdb) bt 
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f38431d8b25 in __GI_abort () at abort.c:79
#2  0x00007f3843231897 in __libc_message (action=action@entry=do_abort,
    fmt=fmt@entry=0x7f384333e057 "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007f3843237fdc in malloc_printerr (
    str=str@entry=0x7f3843340148 "malloc(): mismatching next->prev_size (unsorted)") at malloc.c:5366
#4  0x00007f384323b1e4 in _int_malloc (av=av@entry=0x7f3830000020, bytes=bytes@entry=83)
    at malloc.c:3753
#5  0x00007f384323c662 in __GI___libc_malloc (bytes=bytes@entry=83) at malloc.c:3073
#6  0x0000564703d46071 in dequote (
    str=str@entry=0x7f383000dc91 "fstype=nfs,rw,nosuid,soft,nfsvers=3,context=\"system_u:object_r:user_home_dir_t:s0\"    vm137.gsslab.pnq.redhat.com:/exports/630006445101", origlen=origlen@entry=82,
    logopt=logopt@entry=0) at parse_subs.c:719
#7  0x00007f383bba3eb1 in parse_options (logopt=0, ret=<synthetic pointer>,
    str=0x7f383000dc90 "-fstype=nfs,rw,nosuid,soft,nfsvers=3,context=\"system_u:object_r:user_home_dir_t:s0\"    vm137.gsslab.pnq.redhat.com:/exports/630006445101") at parse_sun.c:470
#8  parse_mount (ap=0x564704677f20, name=0x7f383a50f690 "630006445101", name_len=12,
    mapent=<optimized out>, context=0x7f382c000b80) at parse_sun.c:1368
#9  0x00007f383bdd9588 in lookup_mount (ap=0x564704677f20, name=<optimized out>,
    name_len=<optimized out>, context=0x7f382c000d70) at lookup_file.c:1306
#10 0x0000564703d2e6d1 in do_lookup_mount (ap=ap@entry=0x564704677f20, map=0x7f382c000c10,
    name=name@entry=0x7f383a513c90 "630006445101", name_len=name_len@entry=12) at lookup.c:833
#11 0x0000564703d2eb0f in lookup_name_file_source_instance (ap=ap@entry=0x564704677f20,
    map=map@entry=0x564704678220, name=name@entry=0x7f383a513c90 "630006445101",
    name_len=name_len@entry=12) at lookup.c:974
#12 0x0000564703d2f44c in lookup_nss_mount (ap=ap@entry=0x564704677f20, source=source@entry=0x0,
    name=name@entry=0x7f383a513c90 "630006445101", name_len=12) at lookup.c:1216
#13 0x0000564703d25c18 in do_mount_indirect (arg=<optimized out>) at indirect.c:754
#14 0x00007f3844c452de in start_thread (arg=<optimized out>) at pthread_create.c:486
#15 0x00007f38432b2e83 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
~~~
Observations:
    Length of ths tring `fstype=nfs,rw,nosuid,soft,nfsvers=3,context=\"system_u:object_r:user_home_dir_t:s0\"    vm137.gsslab.pnq.redhat.com:/exports/630006445101` is 137 characters
    However, we have length calculated to `origlen=origlen@entry=82,` 82.
    We then try to malloc LEN + 1 according to the following source code: 
    ~~~
    719             char *ret = malloc(origlen + 1);
    ~~~
    Seems like an error in string length calcualtion that needs to be fixed.


[0x4] Couldn't reproduce the following error, this was seen on the customer system.
=====
Error   : malloc(): corrupted top size
Filename: CUSTOMER_topsize.coredump (private attachment to Red Hat.)
Initial investigation:

~~~
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f6bdc2b2b25 in __GI_abort () at abort.c:79
#2  0x00007f6bdc30b897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f6bdc418057 "%s\n")
    at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007f6bdc311fdc in malloc_printerr (str=str@entry=0x7f6bdc4162e3 "malloc(): corrupted top size") at malloc.c:5366
#4  0x00007f6bdc315445 in _int_malloc (av=av@entry=0x7f6bbc000020, bytes=bytes@entry=50) at malloc.c:4119
#5  0x00007f6bdc316662 in __GI___libc_malloc (bytes=bytes@entry=50) at malloc.c:3073
#6  0x0000564e3704d071 in dequote (str=str@entry=0x7f6bbc0016ba "XXXXXXXXXX:/vol/DC1_IT_automount/export/502004219",
    origlen=origlen@entry=49, logopt=0) at parse_subs.c:719
#7  0x00007f6bd8d081e2 in parse_mount (ap=0x564e3764ad80, name=0x7f6bd2dbf690 "502004219", name_len=9, mapent=<optimized out>,
    context=<optimized out>) at parse_sun.c:1631
#8  0x00007f6bd8f3d588 in lookup_mount (ap=0x564e3764ad80, name=<optimized out>, name_len=<optimized out>, context=0x7f6bc0000d40)
    at lookup_file.c:1306
#9  0x0000564e370356d1 in do_lookup_mount (ap=ap@entry=0x564e3764ad80, map=0x7f6bc0000be0,
    name=name@entry=0x7f6bd2dc3c90 "502004219", name_len=name_len@entry=9) at lookup.c:833
#10 0x0000564e37035b0f in lookup_name_file_source_instance (ap=ap@entry=0x564e3764ad80, map=map@entry=0x564e3764aea0,
    name=name@entry=0x7f6bd2dc3c90 "502004219", name_len=name_len@entry=9) at lookup.c:974
#11 0x0000564e3703644c in lookup_nss_mount (ap=ap@entry=0x564e3764ad80, source=source@entry=0x0,
    name=name@entry=0x7f6bd2dc3c90 "502004219", name_len=9) at lookup.c:1216
#12 0x0000564e3702cc18 in do_mount_indirect (arg=<optimized out>) at indirect.c:754
#13 0x00007f6bddd1f2de in start_thread (arg=<optimized out>) at pthread_create.c:486
#14 0x00007f6bdc38ce83 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
~~~

Observations: 
    No SELINUX `context=` field is seen in this case. 

Conclusion over all these crashes in automount: 
There could be an initial problem like string length calculation as you suspected that may be triggering this behavior.

Please let me know if you would like me to upload any further data or request customer to run any tests.

-Achilles
Comment 8 Achilles Gaikwad 2020-06-01 07:45:36 UTC 
Created attachment 1694027 [details]
coredumps of autofs from my test lab environment
Comment 9 Ian Kent 2020-06-01 11:29:04 UTC 
(In reply to Achilles Gaikwad from comment #5)
> Hello Ian,
> 
> I hope you're doing well! 
> 
> Thank you for looking into this bug report. I really appreciate your help!
> 
> I tried reproducing the issue so that I could get `malloc(): corrupted top
> size` instead got different errors in malloc. 
> 
> Below are the list of items that I faced. Please do read the Observations
> section below. There may be some important pointers there to conclude what's
> causing this issue.
> 
> [0x1] Captured from my local reproducer on RHEL 8 system with
> autofs-5.1.4-40.el8.x86_64.
> =====
> Error   : automount: malloc.c:2396: sysmalloc: Assertion `(old_top ==
> initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE
> && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)'
> failed.
> Filename: E.coredump
> 
> Initial investigation:
> ~~~
> :::
> #16 0x00007fa045fd2eea in mount_mount (ap=0x55bd38311060,
> root=0x55bd38311000 "/mnt/home",
>     name=0x7fa044b79230 "0123456789100", name_len=13,
>     what=0x7fa044b791f0 "vm137.gsslab.pnq.redhat.com:/exports/012345678910e",
>     fstype=<optimized out>,
>     options=0x7fa044b79260
> "rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0",
>     context=0x0) at mount_nfs.c:215
> #17 0x00007fa04620c35d in sun_mount (ap=ap@entry=0x55bd38311060,
> root=<optimized out>,
>     name=<optimized out>, namelen=<optimized out>, loc=<optimized out>,
> loclen=<optimized out>,
>     options=0x7fa044b79260
> "rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0",
>     ctxt=<optimized out>) at parse_sun.c:691
> #18 0x00007fa04620e444 in parse_mount (ap=0x55bd38311060,
> name=0x7fa044b79690 "0123456789100",
>     name_len=13, mapent=<optimized out>, context=<optimized out>) at
> parse_sun.c:1735
> #19 0x00007fa046443588 in lookup_mount (ap=0x55bd38311060, name=<optimized
> out>,
>     name_len=<optimized out>, context=0x7fa03c000d70) at lookup_file.c:1306
> #20 0x000055bd37a9a6d1 in do_lookup_mount (ap=ap@entry=0x55bd38311060,
> map=0x7fa03c000c10,
>     name=name@entry=0x7fa044b7dc90 "0123456789100",
> name_len=name_len@entry=13) at lookup.c:833
> #21 0x000055bd37a9ab0f in lookup_name_file_source_instance
> (ap=ap@entry=0x55bd38311060,
>     map=map@entry=0x55bd38311360, name=name@entry=0x7fa044b7dc90
> "0123456789100",
>     name_len=name_len@entry=13) at lookup.c:974
> #22 0x000055bd37a9b44c in lookup_nss_mount (ap=ap@entry=0x55bd38311060,
> source=source@entry=0x0,
>     name=name@entry=0x7fa044b7dc90 "0123456789100", name_len=13) at
> lookup.c:1216
> #23 0x000055bd37a91c18 in do_mount_indirect (arg=<optimized out>) at
> indirect.c:754
> #24 0x00007fa04b2252de in start_thread (arg=<optimized out>) at
> pthread_create.c:486
> #25 0x00007fa049892e83 in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> ~~~
> 
> Observations: 
>     notice that I requested for a mount of  0123456789100, but somewhere
> down the stack the value
>     got changed to 012345678910e.
>     I do not know yet where the "e" came from.

Yes, I haven't tried to work out what's happening there.

I did see a failure at that location as well but don't think I saw the field
corruption (the added "e"). That could be a lack of initialization problem.

Before I dig deeper I need to check other releases with this build becuase
the number of changes is very small between 8.1 and 8.2, there's a rather
large change between 8.0 and 8.1, we'll see.

> 
> [0x2] Attaching the file named quoted.coredump
> =====
> Error   : malloc(): invalid next size (unsorted)
> Filename: quoted.coredump
> Initial investigation:
> ~~~
> (gdb) bt
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x00007f5134639b25 in __GI_abort () at abort.c:79
> #2  0x00007f5134692897 in __libc_message (action=action@entry=do_abort,
>     fmt=fmt@entry=0x7f513479f057 "%s\n") at ../sysdeps/posix/libc_fatal.c:181
> #3  0x00007f5134698fdc in malloc_printerr (
>     str=str@entry=0x7f51347a1120 "malloc(): invalid next size (unsorted)")
> at malloc.c:5366
> #4  0x00007f513469bebc in _int_malloc (av=av@entry=0x7f5110000020,
> bytes=bytes@entry=83)
>     at malloc.c:3751
> #5  0x00007f513469d662 in __GI___libc_malloc (bytes=bytes@entry=83) at
> malloc.c:3073
> #6  0x00005599ff02d071 in dequote (
>     str=str@entry=0x7f5110001581
> "fstype=nfs,rw,nosuid,soft,nfsvers=3,context=\"system_u:object_r:
> user_home_dir_t:s0\"    vm137.gsslab.pnq.redhat.com:/exports/0123456789100",
> origlen=origlen@entry=82,
>     logopt=logopt@entry=0) at parse_subs.c:719
> #7  0x00007f513108eeb1 in parse_options (logopt=0, ret=<synthetic pointer>,
>     str=0x7f5110001580
> "-fstype=nfs,rw,nosuid,soft,nfsvers=3,context=\"system_u:object_r:
> user_home_dir_t:s0\"    vm137.gsslab.pnq.redhat.com:/exports/0123456789100")
> at parse_sun.c:470
> #8  parse_mount (ap=0x5599ffa73140, name=0x7f512b7f7690 "0123456789100",
> name_len=13,
>     mapent=<optimized out>, context=0x7f5120000b80) at parse_sun.c:1368
> #9  0x00007f51312c4588 in lookup_mount (ap=0x5599ffa73140, name=<optimized
> out>,
>     name_len=<optimized out>, context=0x7f5120000d70) at lookup_file.c:1306
> #10 0x00005599ff0156d1 in do_lookup_mount (ap=ap@entry=0x5599ffa73140,
> map=0x7f5120000c10,
>     name=name@entry=0x7f512b7fbc90 "0123456789100",
> name_len=name_len@entry=13) at lookup.c:833
> #11 0x00005599ff015b0f in lookup_name_file_source_instance
> (ap=ap@entry=0x5599ffa73140,
>     map=map@entry=0x5599ffa73440, name=name@entry=0x7f512b7fbc90
> "0123456789100",
>     name_len=name_len@entry=13) at lookup.c:974
> #12 0x00005599ff01644c in lookup_nss_mount (ap=ap@entry=0x5599ffa73140,
> source=source@entry=0x0,
>     name=name@entry=0x7f512b7fbc90 "0123456789100", name_len=13) at
> lookup.c:1216
> #13 0x00005599ff00cc18 in do_mount_indirect (arg=<optimized out>) at
> indirect.c:754
> #14 0x00007f51360a62de in start_thread (arg=<optimized out>) at
> pthread_create.c:486
> #15 0x00007f5134713e83 in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> ~~~
> Observations: 
>     Notice that the context is quoted in #6.
>     The issue either doesn't occur or is difficult to reproduce without the
> quotes.
> 
> [0x3]
> ===== 
> Error   : malloc(): mismatching next->prev_size (unsorted)
> Filename: mismatch.coredump
> Initial investigation:
> 
> ~~~
> (gdb) bt 
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x00007f38431d8b25 in __GI_abort () at abort.c:79
> #2  0x00007f3843231897 in __libc_message (action=action@entry=do_abort,
>     fmt=fmt@entry=0x7f384333e057 "%s\n") at ../sysdeps/posix/libc_fatal.c:181
> #3  0x00007f3843237fdc in malloc_printerr (
>     str=str@entry=0x7f3843340148 "malloc(): mismatching next->prev_size
> (unsorted)") at malloc.c:5366
> #4  0x00007f384323b1e4 in _int_malloc (av=av@entry=0x7f3830000020,
> bytes=bytes@entry=83)
>     at malloc.c:3753
> #5  0x00007f384323c662 in __GI___libc_malloc (bytes=bytes@entry=83) at
> malloc.c:3073
> #6  0x0000564703d46071 in dequote (
>     str=str@entry=0x7f383000dc91
> "fstype=nfs,rw,nosuid,soft,nfsvers=3,context=\"system_u:object_r:
> user_home_dir_t:s0\"    vm137.gsslab.pnq.redhat.com:/exports/630006445101",
> origlen=origlen@entry=82,
>     logopt=logopt@entry=0) at parse_subs.c:719
> #7  0x00007f383bba3eb1 in parse_options (logopt=0, ret=<synthetic pointer>,
>     str=0x7f383000dc90
> "-fstype=nfs,rw,nosuid,soft,nfsvers=3,context=\"system_u:object_r:
> user_home_dir_t:s0\"    vm137.gsslab.pnq.redhat.com:/exports/630006445101")
> at parse_sun.c:470
> #8  parse_mount (ap=0x564704677f20, name=0x7f383a50f690 "630006445101",
> name_len=12,
>     mapent=<optimized out>, context=0x7f382c000b80) at parse_sun.c:1368
> #9  0x00007f383bdd9588 in lookup_mount (ap=0x564704677f20, name=<optimized
> out>,
>     name_len=<optimized out>, context=0x7f382c000d70) at lookup_file.c:1306
> #10 0x0000564703d2e6d1 in do_lookup_mount (ap=ap@entry=0x564704677f20,
> map=0x7f382c000c10,
>     name=name@entry=0x7f383a513c90 "630006445101",
> name_len=name_len@entry=12) at lookup.c:833
> #11 0x0000564703d2eb0f in lookup_name_file_source_instance
> (ap=ap@entry=0x564704677f20,
>     map=map@entry=0x564704678220, name=name@entry=0x7f383a513c90
> "630006445101",
>     name_len=name_len@entry=12) at lookup.c:974
> #12 0x0000564703d2f44c in lookup_nss_mount (ap=ap@entry=0x564704677f20,
> source=source@entry=0x0,
>     name=name@entry=0x7f383a513c90 "630006445101", name_len=12) at
> lookup.c:1216
> #13 0x0000564703d25c18 in do_mount_indirect (arg=<optimized out>) at
> indirect.c:754
> #14 0x00007f3844c452de in start_thread (arg=<optimized out>) at
> pthread_create.c:486
> #15 0x00007f38432b2e83 in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> ~~~
> Observations:
>     Length of ths tring
> `fstype=nfs,rw,nosuid,soft,nfsvers=3,context=\"system_u:object_r:
> user_home_dir_t:s0\"    vm137.gsslab.pnq.redhat.com:/exports/630006445101`
> is 137 characters
>     However, we have length calculated to `origlen=origlen@entry=82,` 82.
>     We then try to malloc LEN + 1 according to the following source code: 
>     ~~~
>     719             char *ret = malloc(origlen + 1);
>     ~~~
>     Seems like an error in string length calcualtion that needs to be fixed.

Well, maybe not.

I pulled out those functions and checked them with the strings that are
being used. That length is the next chunk of white space delimited map
entry chunks not the full length of string. The length calculations
looked ok to me.

> 
> 
> [0x4] Couldn't reproduce the following error, this was seen on the customer
> system.
> =====
> Error   : malloc(): corrupted top size
> Filename: CUSTOMER_topsize.coredump (private attachment to Red Hat.)
> Initial investigation:
> 
> ~~~
> (gdb) bt
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #1  0x00007f6bdc2b2b25 in __GI_abort () at abort.c:79
> #2  0x00007f6bdc30b897 in __libc_message (action=action@entry=do_abort,
> fmt=fmt@entry=0x7f6bdc418057 "%s\n")
>     at ../sysdeps/posix/libc_fatal.c:181
> #3  0x00007f6bdc311fdc in malloc_printerr (str=str@entry=0x7f6bdc4162e3
> "malloc(): corrupted top size") at malloc.c:5366
> #4  0x00007f6bdc315445 in _int_malloc (av=av@entry=0x7f6bbc000020,
> bytes=bytes@entry=50) at malloc.c:4119
> #5  0x00007f6bdc316662 in __GI___libc_malloc (bytes=bytes@entry=50) at
> malloc.c:3073
> #6  0x0000564e3704d071 in dequote (str=str@entry=0x7f6bbc0016ba
> "XXXXXXXXXX:/vol/DC1_IT_automount/export/502004219",
>     origlen=origlen@entry=49, logopt=0) at parse_subs.c:719
> #7  0x00007f6bd8d081e2 in parse_mount (ap=0x564e3764ad80,
> name=0x7f6bd2dbf690 "502004219", name_len=9, mapent=<optimized out>,
>     context=<optimized out>) at parse_sun.c:1631
> #8  0x00007f6bd8f3d588 in lookup_mount (ap=0x564e3764ad80, name=<optimized
> out>, name_len=<optimized out>, context=0x7f6bc0000d40)
>     at lookup_file.c:1306
> #9  0x0000564e370356d1 in do_lookup_mount (ap=ap@entry=0x564e3764ad80,
> map=0x7f6bc0000be0,
>     name=name@entry=0x7f6bd2dc3c90 "502004219", name_len=name_len@entry=9)
> at lookup.c:833
> #10 0x0000564e37035b0f in lookup_name_file_source_instance
> (ap=ap@entry=0x564e3764ad80, map=map@entry=0x564e3764aea0,
>     name=name@entry=0x7f6bd2dc3c90 "502004219", name_len=name_len@entry=9)
> at lookup.c:974
> #11 0x0000564e3703644c in lookup_nss_mount (ap=ap@entry=0x564e3764ad80,
> source=source@entry=0x0,
>     name=name@entry=0x7f6bd2dc3c90 "502004219", name_len=9) at lookup.c:1216
> #12 0x0000564e3702cc18 in do_mount_indirect (arg=<optimized out>) at
> indirect.c:754
> #13 0x00007f6bddd1f2de in start_thread (arg=<optimized out>) at
> pthread_create.c:486
> #14 0x00007f6bdc38ce83 in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> ~~~
> 
> Observations: 
>     No SELINUX `context=` field is seen in this case. 
> 
> Conclusion over all these crashes in automount: 
> There could be an initial problem like string length calculation as you
> suspected that may be triggering this behavior.
> 
> Please let me know if you would like me to upload any further data or
> request customer to run any tests.

I'll continue with my checks and get back if I need more info.

It's worth realizing that this sort of error could be almost anywhere
in code executed prior to reaching this point and there's no real clues
as to where the problem my be, it's going to be hard to track down.

Interestingly I cannot reproduce this on F31 at all with the current
release of autofs on there, I think analysing the patches that aren't
present on RHEL is worth a shot too (although I don't think there are
that many ...) there.

Ian
Comment 10 Achilles Gaikwad 2020-06-01 17:42:16 UTC 
>Before I dig deeper I need to check other releases with this build becuase
>the number of changes is very small between 8.1 and 8.2, there's a rather
>large change between 8.0 and 8.1, we'll see.

I've tested it, the issue happens on 8.0, 8.1 and 8.2.
The issue doesn't appear to be on RHEL 7. 
The issue even appears to be on Fedora and upstream.

>Well, maybe not.

>I pulled out those functions and checked them with the strings that are
>being used. That length is the next chunk of white space delimited map
>entry chunks not the full length of string. The length calculations
>looked ok to me.

Understood, Thanks for the clarification.

>It's worth realizing that this sort of error could be almost anywhere
>in code executed prior to reaching this point and there's no real clues
>as to where the problem my be, it's going to be hard to track down.

Yes it is indeed difficult. 

>Interestingly I cannot reproduce this on F31 at all with the current
>release of autofs on there, I think analysing the patches that aren't
>present on RHEL is worth a shot too (although I don't think there are
>that many ...) there.

Understood. I therefore built a fedora 32 system and autofs from 
https://git.kernel.org/pub/scm/linux/storage/autofs/autofs.git

Results and Observations follow,

o automount is v5.1.6

~~~
# automount -V

Linux automount version 5.1.6

Directories:
        config dir:     /etc/sysconfig
        maps dir:       /etc
        modules dir:    /usr/lib/autofs

Compile options:
  WITH_LIBTIRPC
~~~

o Error that I am trying to reproduce is : 
    automount program crashes with "malloc(): invalid next size (unsorted)"

o Debug logs : 

 - I did a ls {A..Z} , and this mounted A thru Z directories on the nfs-client.
~~~
mount_mount: mount(nfs): mounted 192.168.2.163:/exports/Z on /mnt/home/Z
dev_ioctl_send_ready: token = 67
mounted /mnt/home/Z
~~~
 - After this I ran the following command and found that autofs crashed: 

~~~
# for i in {1..1000} ; do ls /mnt/home/0123456789$i ; done
~~~

 - Then autofs crashes trying to mount 01234567891, here too we see "e" added as a suffix: loc=192.168.2.163:/exports/012345678e

~~~
handle_packet: type = 3
handle_packet_missing_indirect: token 68, name 01234567891, request pid 5030
attempting to mount entry /mnt/home/01234567891
lookup_mount: lookup(file): looking up 01234567891
lookup_mount: lookup(file): 01234567891 -> -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"     192.168.2.163:/exports/&
parse_mount: parse(sun): expanded entry: -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"     192.168.2.163:/exports/01234567891
parse_mount: parse(sun): gathered options: fstype=nfs,rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0
parse_mount: parse(sun): dequote("192.168.2.163:/exports/012345678e") -> 192.168.2.163:/exports/012345678e
parse_mount: parse(sun): core of entry: options=fstype=nfs,rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0, loc=192.168.2.163:/exports/012345678e
sun_mount: parse(sun): mounting root /mnt/home, mountpoint 01234567891, what 192.168.2.163:/exports/012345678e, fstype nfs, options rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0
mount(nfs): root=/mnt/home name=01234567891 what=192.168.2.163:/exports/012345678e, fstype=nfs, options=rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0
mount(nfs): nfs options="rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0", nobind=0, nosymlink=0, ro=0
get_nfs_info: called with host 192.168.2.163(192.168.2.163) proto 6 version 0x20
automount: malloc.c:2379: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) ==
 0)' failed.
Aborted (core dumped)
~~~

 - I feel that the crash is due to different reason here, but the symptoms look similar.
 
~~~
 automount: malloc.c:2379: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) ==
 0)' failed.
~~~

o Another attempt and I managed to reproduce the issue

~~~
handle_packet: type = 3
handle_packet_missing_indirect: token 30, name getenforce, request pid 2684
attempting to mount entry /mnt/home/getenforce
lookup_mount: lookup(file): looking up getenforce
lookup_mount: lookup(file): getenforce -> -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"     192.168.2.163:/exports/&
parse_mount: parse(sun): expanded entry: -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"     192.168.2.163:/exports/getenforce
malloc(): invalid next size (unsorted)
Aborted (core dumped)
~~~

This time instead of doing a `ls` in a loop, I executed getenforce and tried using tab completion. I assume this would happen with any command.

From /mnt/home which is the autofs managed directory. 

One terminal
~~~
[root@build home]# geten
<hung>
~~~

Another terminal where I ran autofs:
~~~
handle_packet: type = 3
handle_packet_missing_indirect: token 33, name getenforce, request pid 2895
attempting to mount entry /mnt/home/getenforce
lookup_mount: lookup(file): looking up getenforce
lookup_mount: lookup(file): getenforce -> -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"     192.168.2.163:/exports/&
parse_mount: parse(sun): expanded entry: -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"     192.168.2.163:/exports/getenforce
malloc(): invalid next size (unsorted)
Aborted (core dumped)
~~~

Fedora 31: 

o First attempt at reproducer. 
~~~
make[1]: Leaving directory '/root/devel/autofs/man'
[root@fed31 autofs]# automount -V

Linux automount version 5.1.6

Directories:
        config dir:     /etc/sysconfig
        maps dir:       /etc
        modules dir:    /usr/lib/autofs

Compile options:
  WITH_LIBTIRPC
~~~


~~~
handle_packet: type = 3
handle_packet_missing_indirect: token 79, name getenf, request pid 5822
attempting to mount entry /mnt/home/getenf
lookup_mount: lookup(file): looking up getenf
lookup_mount: lookup(file): getenf -> -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"    192.168.2.163:/exports/&
parse_mount: parse(sun): expanded entry: -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"    192.168.2.163:/exports/getenf
parse_mount: parse(sun): gathered options: fstype=nfs,rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0
parse_mount: parse(sun): dequote("192.168.2.163:/exports/getenf") -> 192.168.2.163:/exports/getenf
parse_mount: parse(sun): core of entry: options=fstype=nfs,rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0, loc=192.168.2.163:/exports/getenf
sun_mount: parse(sun): mounting root /mnt/home, mountpoint getenf, what 192.168.2.163:/exports/getenf, fstype nfs, options rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0
mount(nfs): root=/mnt/home name=getenf what=192.168.2.163:/exports/getenf, fstype=nfs, options=rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0
mount(nfs): nfs options="rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0", nobind=0, nosymlink=0, ro=0
get_nfs_info: called with host 192.168.2.163(192.168.2.163) proto 6 version 0x20
get_nfs_info: nfs v3 rpc ping time: 0.000328
get_nfs_info: host 192.168.2.163 cost 328 weight 0
get_nfs_info: called with host 192.168.2.163(192.168.2.163) proto 17 version 0x20
get_nfs_info: nfs v3 rpc ping time: 0.000279
get_nfs_info: host 192.168.2.163 cost 279 weight 0
prune_host_list: selected subset of hosts that support NFS3 over TCP
mount_mount: mount(nfs): calling mkdir_path /mnt/home/getenf
mount(nfs): calling mount -t nfs -s -o rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0 192.168.2.163:/exports/getenf /mnt/home/getenf
>> mount.nfs: mounting 192.168.2.163:/exports/getenf failed, reason given by server: No such file or directory
mount(nfs): nfs: mount failure 192.168.2.163:/exports/getenf on /mnt/home/getenf
dev_ioctl_send_fail: token = 79
handle_packet: type = 3
handle_packet_missing_indirect: token 80, name getenforce, request pid 5822
failed to mount /mnt/home/getenf
attempting to mount entry /mnt/home/getenforce
lookup_mount: lookup(file): looking up getenforce
lookup_mount: lookup(file): getenforce -> -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"    192.168.2.163:/exports/&
parse_mount: parse(sun): expanded entry: -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"    192.168.2.163:/exports/getenforce
malloc(): mismatching next->prev_size (unsorted)
Aborted (core dumped)
~~~

o Attempt 2 also crashed automount, however the message that malloc prints is `mismatching next->prev_size`
  typed `getenf` and press <TAB><TAB> for bash completion. I suspect this would occur with any string.
~~~
handle_packet: type = 3
handle_packet_missing_indirect: token 28, name getenforce, request pid 634
failed to mount /mnt/home/getenfor
attempting to mount entry /mnt/home/getenforce
lookup_mount: lookup(file): looking up getenforce
lookup_mount: lookup(file): getenforce -> -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"    192.168.2.163:/exports/&
parse_mount: parse(sun): expanded entry: -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"    192.168.2.163:/exports/getenforce
malloc(): mismatching next->prev_size (unsorted)
Aborted (core dumped)
~~~

o Attempt 3 succeeded 

~~~
handle_packet: type = 3
handle_packet_missing_indirect: token 30, name 0123456789, request pid 860
attempting to mount entry /mnt/home/0123456789
lookup_mount: lookup(file): looking up 0123456789
lookup_mount: lookup(file): 0123456789 -> -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"    192.168.2.163:/exports/&
parse_mount: parse(sun): expanded entry: -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"    192.168.2.163:/exports/0123456789
malloc(): invalid next size (unsorted)
Aborted (core dumped)
~~~

o Attempt 4 succeeded as well.
 did a `cd` to 01234567889 this time.
~~~
handle_packet: type = 3
handle_packet_missing_indirect: token 34, name 01234567889, request pid 1074
attempting to mount entry /mnt/home/01234567889
lookup_mount: lookup(file): looking up 01234567889
lookup_mount: lookup(file): 01234567889 -> -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"    192.168.2.163:/exports/&
parse_mount: parse(sun): expanded entry: -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"    192.168.2.163:/exports/01234567889
malloc(): invalid next size (unsorted)
Aborted (core dumped)
~~~

o Attempt 5 we got 'e' as suffix.

~~~
handle_packet: type = 3
handle_packet_missing_indirect: token 35, name 0123456789, request pid 1187
attempting to mount entry /mnt/home/0123456789
lookup_mount: lookup(file): looking up 0123456789
lookup_mount: lookup(file): 0123456789 -> -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"    192.168.2.163:/exports/&
parse_mount: parse(sun): expanded entry: -fstype=nfs,rw,nosuid,soft,nfsvers=3,context="system_u:object_r:user_home_dir_t:s0"    192.168.2.163:/exports/0123456789
parse_mount: parse(sun): gathered options: fstype=nfs,rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0
parse_mount: parse(sun): dequote("192.168.2.163:/exports/0123456789e") -> 192.168.2.163:/exports/0123456789e
parse_mount: parse(sun): core of entry: options=fstype=nfs,rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0, loc=192.168.2.163:/exports/0123456789e
sun_mount: parse(sun): mounting root /mnt/home, mountpoint 0123456789, what 192.168.2.163:/exports/0123456789e, fstype nfs, options rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0
mount(nfs): root=/mnt/home name=0123456789 what=192.168.2.163:/exports/0123456789e, fstype=nfs, options=rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0
mount(nfs): nfs options="rw,nosuid,soft,nfsvers=3,context=system_u:object_r:user_home_dir_t:s0", nobind=0, nosymlink=0, ro=0
get_nfs_info: called with host 192.168.2.163(192.168.2.163) proto 6 version 0x20
automount: malloc.c:2379: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) ==
 0)' failed.
Aborted (core dumped)
~~~

o Got a coredump, having a look at its backtrace:

~~~
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007fc0d6b058d9 in __GI_abort () at abort.c:79
#2  0x00007fc0d6b67a4a in __malloc_assert (
    assertion=assertion@entry=0x7fc0d6c71e38 "(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0
)", file=file@entry=0x7fc0d6c6dff5 "malloc.c", line=line@entry=2379, function=function@entry=0x7fc0d6c725c0 <__PRETTY_FUNCTION__.13025> "sysmalloc") at malloc.c:298
#3  0x00007fc0d6b6a26f in sysmalloc (nb=nb@entry=65552, av=av@entry=0x7fc0c8000020) at malloc.c:2379
#4  0x00007fc0d6b6b022 in _int_malloc (av=av@entry=0x7fc0c8000020, bytes=bytes@entry=65536) at malloc.c:4141
#5  0x00007fc0d6b6cf05 in __libc_calloc (n=n@entry=1, elem_size=elem_size@entry=65536) at malloc.c:3428
#6  0x00007fc0d6cd8704 in xdrrec_create (xdrs=xdrs@entry=0x7fc0c8004318, sendsize=<optimized out>, sendsize@entry=65536, recvsize=<optimized out>, tcp_handle=0x7fc0c80042c0,
    readit=readit@entry=0x7fc0d6cca980 <read_vc>, writeit=writeit@entry=0x7fc0d6ccab40 <write_vc>) at xdr_rec.c:765
#7  0x00007fc0d6ccb488 in clnt_vc_create (fd=<optimized out>, raddr=<optimized out>, prog=100003, vers=3, sendsz=65536, recvsz=<optimized out>) at clnt_vc.c:326
#8  0x00007fc0d5cd8de9 in ?? () from /usr/lib/autofs/mount_nfs.so
#9  0x00007fc0d5cd902a in ?? () from /usr/lib/autofs/mount_nfs.so
#10 0x00007fc0d5cd9568 in rpc_tcp_getclient () from /usr/lib/autofs/mount_nfs.so
#11 0x00007fc0d5cd68d1 in ?? () from /usr/lib/autofs/mount_nfs.so
#12 0x00007fc0d5cd8011 in prune_host_list () from /usr/lib/autofs/mount_nfs.so
#13 0x00007fc0d5cd5a23 in mount_mount () from /usr/lib/autofs/mount_nfs.so
#14 0x00007fc0d5d0d6c5 in ?? () from /usr/lib/autofs/parse_sun.so
#15 0x00007fc0d5d0f574 in parse_mount () from /usr/lib/autofs/parse_sun.so
#16 0x00007fc0d5d42ee0 in lookup_mount () from /usr/lib/autofs/lookup_file.so
#17 0x0000564292e496bf in do_lookup_mount ()
#18 0x0000564292e49a9c in ?? ()
#19 0x0000564292e4a4cd in lookup_nss_mount ()
#20 0x0000564292e409e8 in ?? ()
#21 0x00007fc0d6cf54e2 in start_thread (arg=<optimized out>) at pthread_create.c:479
#22 0x00007fc0d6be1643 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
~~~

Achilles
Comment 11 Ian Kent 2020-06-02 05:36:33 UTC 
Created attachment 1694247 [details]
Patch - initialize struct addrinfo for getaddrinfo() calls
Comment 12 Ian Kent 2020-06-02 05:37:18 UTC 
Created attachment 1694248 [details]
Patch - fix quoted string length calc in expandsunent()
Comment 38 errata-xmlrpc 2020-11-04 02:06:04 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 (autofs bug fix and enhancement update), 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/RHBA-2020:4573
Note You need to log in before you can comment on or make changes to this bug.