[Bug 1927745] Re: Non-thread-safe functions used in multi-threaded rpc.gssd
Andreas Hasenack
1927745 at bugs.launchpad.net
Mon May 10 13:52:45 UTC 2021
Reproducer tool from RH bug
** Description changed:
[Impact]
- * An explanation of the effects of the bug on users and
+ * An explanation of the effects of the bug on users and
- * justification for backporting the fix to the stable release.
+ * justification for backporting the fix to the stable release.
- * In addition, it is helpful, but not required, to include an
- explanation of how the upload fixes this bug.
+ * In addition, it is helpful, but not required, to include an
+ explanation of how the upload fixes this bug.
[Test Plan]
+ # Create a bionic VM. Login and get its ip, and take note of it:
+ export IP=$(ip route get default 8.8.8.8 | grep ^8 | awk '{print $7}')
+ echo $IP
- * detailed instructions how to reproduce the bug
+ # adjust /etc/hosts:
+ echo "$IP $(hostname).example.com" | sudo tee -a /etc/hosts
- * these should allow someone who is not familiar with the affected
- package to reproduce the bug and verify that the updated package fixes
- the problem.
+ # adjust /etc/resolv.conf:
+ echo "search example.com" | sudo tee -a /etc/resolv.conf
- * if other testing is appropriate to perform before landing this update,
- this should also be described here.
+ # verify hostname -f returns the fqdn of the vm, i.e., a name with the .example.com domain:
+ hostname -f
+
+ # Run these commands, and when asked:
+ # - for realm: EXAMPLE.COM
+ # - for kdc and admin server: use the vm's IP
+
+ sudo apt update && apt install nfs-server krb5-kdc krb5-admin-server
+ krb5-user gcc
+
+
+ # adjust nfs config and restart the nfs server:
+ sudo sed -r -i "s,^NEED_SVCGSSD=.*,NEED_SVCGSSD=\"yes\"," /etc/default/nfs-kernel-server
+ sudo sed -r -i "s,^NEED_GSSD=.*,NEED_GSSD=\"yes\"," /etc/default/nfs-common
+ sudo systemctl restart nfs-server
+
+
+ # create a kerberos realm. When prompted, use any password you want:
+ sudo krb5_newrealm
+
+ # create an nfs service ticket, and store it in the keytab
+ sudo kadmin.local -q "addprinc -randkey nfs/$(hostname -f)"
+ sudo kadmin.local -q "ktadd nfs/$(hostname -f)"
+
+
+ # create test directories
+ sudo mkdir -p /mnt/test_krb5/
+ sudo mkdir -p /export
+ sudo touch /export/foo
+
+ # configure an nfs export:
+ echo "/export *(sec=krb5,rw,sync,no_subtree_check)" | sudo tee -a /etc/exports
+ sudo exportfs -rva
+
+ # confirm it's available
+ sudo showmount -e localhost
+
+
+ # mount it
+ sudo mount $(hostname -f):/export /mnt/test_krb5/
+ sudo ls -la /mnt/test_krb5
+
+
+ # download bug attachments
+ (TBD)
+
+ # build reproducer
+ gcc stat_as.c -o stat_as
+
+ # run as root
+ sudo ./bz1419280_test_threads
+
+ # wait
+ # Once you get the confirmation:
+ calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035
+ reproduced the bug after 114 iterations
+
+ # Check for a "stat_as" D state process:
+ $ ps axw|grep stat_as
+ 17814 pts/1 D 0:00 ./stat_as /mnt/test_krb5/foo 9995 10035
+
+ # With the updated packages, the script will not detect the bug and never stop.
+
[Where problems could occur]
- * Think about what the upload changes in the software. Imagine the change is
- wrong or breaks something else: how would this show up?
+ * Think about what the upload changes in the software. Imagine the change is
+ wrong or breaks something else: how would this show up?
- * It is assumed that any SRU candidate patch is well-tested before
- upload and has a low overall risk of regression, but it's important
- to make the effort to think about what ''could'' happen in the
- event of a regression.
+ * It is assumed that any SRU candidate patch is well-tested before
+ upload and has a low overall risk of regression, but it's important
+ to make the effort to think about what ''could'' happen in the
+ event of a regression.
- * This must '''never''' be "None" or "Low", or entirely an argument as to why
- your upload is low risk.
+ * This must '''never''' be "None" or "Low", or entirely an argument as to why
+ your upload is low risk.
- * This both shows the SRU team that the risks have been considered,
- and provides guidance to testers in regression-testing the SRU.
+ * This both shows the SRU team that the risks have been considered,
+ and provides guidance to testers in regression-testing the SRU.
[Other Info]
-
- * Anything else you think is useful to include
- * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
- * and address these questions in advance
+
+ * Anything else you think is useful to include
+ * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
+ * and address these questions in advance
[Original Description]
Fixed in focal and later, due to sync from debian
Bionic affected.
I'll add a proper description in a moment.
RH: https://bugzilla.redhat.com/show_bug.cgi?id=1419280
Debian BTS: https://bugs.debian.org/895381
ML: http://www.spinics.net/lists/linux-nfs/msg62111.html
ML: http://www.spinics.net/lists/linux-nfs/msg62099.html
** Attachment added: "stat_as.c"
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496166/+files/stat_as.c
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to nfs-utils in Ubuntu.
https://bugs.launchpad.net/bugs/1927745
Title:
Non-thread-safe functions used in multi-threaded rpc.gssd
Status in nfs-utils package in Ubuntu:
Fix Released
Status in nfs-utils source package in Bionic:
In Progress
Status in nfs-utils package in Debian:
Fix Released
Status in nfs-utils package in Fedora:
Fix Released
Bug description:
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Plan]
# Create a bionic VM. Login and get its ip, and take note of it:
export IP=$(ip route get default 8.8.8.8 | grep ^8 | awk '{print $7}')
echo $IP
# adjust /etc/hosts:
echo "$IP $(hostname).example.com" | sudo tee -a /etc/hosts
# adjust /etc/resolv.conf:
echo "search example.com" | sudo tee -a /etc/resolv.conf
# verify hostname -f returns the fqdn of the vm, i.e., a name with the .example.com domain:
hostname -f
# Run these commands, and when asked:
# - for realm: EXAMPLE.COM
# - for kdc and admin server: use the vm's IP
sudo apt update && sudo apt install nfs-server krb5-kdc krb5-admin-
server krb5-user gcc
# create a kerberos realm. When prompted, use any password you want:
sudo krb5_newrealm
# create an nfs service ticket, and store it in the keytab
sudo kadmin.local -q "addprinc -randkey nfs/$(hostname -f)"
sudo kadmin.local -q "ktadd nfs/$(hostname -f)"
# create test directories
sudo mkdir -p /mnt/test_krb5/
sudo mkdir -p /export
sudo touch /export/foo
# adjust nfs config and restart the nfs server:
sudo sed -r -i "s,^NEED_SVCGSSD=.*,NEED_SVCGSSD=\"yes\"," /etc/default/nfs-kernel-server
sudo sed -r -i "s,^NEED_GSSD=.*,NEED_GSSD=\"yes\"," /etc/default/nfs-common
sudo systemctl restart nfs-server
# configure an nfs export:
echo "/export *(sec=krb5,rw,sync,no_subtree_check)" | sudo tee -a /etc/exports
sudo exportfs -rva
# confirm it's available
sudo showmount -e localhost
# mount it
sudo mount $(hostname -f):/export /mnt/test_krb5/
sudo ls -la /mnt/test_krb5
# download bug attachments
wget -ct0 https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496166/+files/stat_as.c https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496167/+files/bz1419280_test_threads
chmod +x bz1419280_test_threads
# build reproducer
gcc stat_as.c -o stat_as
# run test script as root. It may take a few minutes to trigger the bug
sudo ./bz1419280_test_threads
# wait
# Once you get the confirmation:
calling stat on '/mnt/test_krb5/foo' with uids 9995 through 10035
reproduced the bug after 114 iterations
# Check for a "stat_as" D state process:
$ ps axw|grep stat_as
17814 pts/1 D 0:00 ./stat_as /mnt/test_krb5/foo 9995 10035
# With the updated packages, the script will not detect the bug and
never stop.
[Where problems could occur]
* Think about what the upload changes in the software. Imagine the change is
wrong or breaks something else: how would this show up?
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This must '''never''' be "None" or "Low", or entirely an argument as to why
your upload is low risk.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
Fixed in focal and later, due to sync from debian
Bionic affected.
I'll add a proper description in a moment.
RH: https://bugzilla.redhat.com/show_bug.cgi?id=1419280
Debian BTS: https://bugs.debian.org/895381
ML: http://www.spinics.net/lists/linux-nfs/msg62111.html
ML: http://www.spinics.net/lists/linux-nfs/msg62099.html
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+subscriptions
More information about the foundations-bugs
mailing list