[Bug 1927745] Re: Non-thread-safe functions used in multi-threaded rpc.gssd
Andreas Hasenack
1927745 at bugs.launchpad.net
Mon May 10 13:53:01 UTC 2021
Reproducer script from RH bug
** Attachment added: "bz1419280_test_threads"
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1927745/+attachment/5496167/+files/bz1419280_test_threads
** Description changed:
[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
+ echo "$IP $(hostname).example.com" | sudo tee -a /etc/hosts
# adjust /etc/resolv.conf:
- echo "search example.com" | sudo tee -a /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 && 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
-
+ 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
+ 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)"
-
+ 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 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
+ 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
-
+ sudo showmount -e localhost
# mount it
- sudo mount $(hostname -f):/export /mnt/test_krb5/
+ sudo mount $(hostname -f):/export /mnt/test_krb5/
sudo ls -la /mnt/test_krb5
-
# download bug attachments
- (TBD)
+ 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
+ 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.
+ # 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?
* 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
** Description changed:
[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 && apt install nfs-server krb5-kdc krb5-admin-server
- krb5-user gcc
+ sudo apt update && sudo 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
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 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?
* 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
** Description changed:
[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
- # 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
+
+ # 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 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?
* 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
** Description changed:
[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 as root
+ # 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
--
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