[Desktop-packages] [Bug 1930359] Re: glib2.0: Uninitialised memory is written to gschema.compiled, failure to parse this file leads to gdm, gnome-shell failing to start
** Changed in: glib
Status: Unknown => Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1930359
Title:
glib2.0: Uninitialised memory is written to gschema.compiled, failure
to parse this file leads to gdm, gnome-shell failing to start
Status in GLib:
Fix Released
Status in glib2.0 package in Ubuntu:
Fix Released
Status in glib2.0 source package in Focal:
Fix Released
Bug description:
[Impact]
A recent SRU of mutter 3.36.9-0ubuntu0.20.04.1 caused an outage for a
user with 300 VDIs running Focal, where GNOME applications would fail
to start, and if you reboot, gdm and gnome-shell both fail to start,
and you are left with a black screen and a blinking cursor.
After much investigation, mutter was not at fault. Instead, mutter-
common calls the libglib2.0-0 hook on upgrade:
Processing triggers for libglib2.0-0:amd64 (2.64.6-1~ubuntu20.04.3)
...
This in turn calls glib-compile-schemas to recompile the gsettings
gschema cache, from the files in /usr/share/glib-2.0/schemas/. The
result is a binary gschemas.compiled file, which is loaded by
libglib2.0 on every invocation of a GNOME application, or gdm or
gnome-shell to fetch application default settings.
Now, glib2.0 2.64.6-1~ubuntu20.04.3 in Focal has some non-
deterministic behaviour when calling glib-compile-schemas, causing
generated gschemas.compiled files to have differing contents on each
run:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 D0
3771 A4 DB
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 68
3771 A4 30
3772 55 56
The bytes on the left are from a corrupted gschemas.compiled provided
by an affected user. The changing bytes on the right are non-
deterministic.
I ran valgrind over glib-compile-schemas, and found that we are
writing to uninitialised memory.
https://paste.ubuntu.com/p/hvZccwdzxz/
What is happening is that a submodule of glib, gvdb, contains the
logic for serialising the gschema data structures, and when it
allocates a buffer to store the eventual gschemas.compiled file, it
does not initialise it.
When we populate the fields in the buffer, some bytes are never
overwritten, and these junk bytes find themselves written to
gschemas.compiled.
On boot, when gdm and gnome-shell attempt to parse and load this
corrupted gschemas.compiled file, it can't parse the junk bytes, and
raises and error, which propagates up to a breakpoint in glib logging,
but no debugger is present, so the kernel traps the breakpoint, and
terminates the library, and the calling application, e.g. gdm.
The result is that the user is left starting at a black screen with a
blinking pointer.
[Testcase]
On a Focal system, simply run valgrind over glib-compile-schemas:
# valgrind glib-compile-schemas /usr/share/glib-2.0/schemas
You will get output like this, with the warning "Syscall param
write(buf) points to uninitialised byte(s)":
https://paste.ubuntu.com/p/hvZccwdzxz/
If you happen to have a large amount of gschema overrides present on
your system, like my affected user does, you can save a copy of a
generated gschema.compiled to your home directory and bindiff it
against recompiles:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cp /usr/share/glib-2.0/schemas/gschema.compiled
/home/ubuntu/schemas/gschemas.compiled
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
If you install the test package from the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf311791-test
When you run valgrind, it will report a clean run with no writing to
uninitialised buffers, and all invocations of glib-compile-schemas
will be deterministic, and generate the file same with the same sha256
hash every time. The unwritten bytes if you do a bindiff from before
and after will be all set to zero.
[Where problems can occur]
I am doubtful that any programs are relying on buggy non-deterministic
behaviour from random bytes found in uninitialised memory,
[Desktop-packages] [Bug 1930359] Re: glib2.0: Uninitialised memory is written to gschema.compiled, failure to parse this file leads to gdm, gnome-shell failing to start
This bug was fixed in the package glib2.0 - 2.64.6-1~ubuntu20.04.4
---
glib2.0 (2.64.6-1~ubuntu20.04.4) focal; urgency=medium
* Initialise memory used for file builder buffers to zero, since memory
artifacts found themseleves into gschema.compiled files, leading to glib
being unable to parse the gschema.compiled files, causing gdm, gnome-shell
and various gnome applications to fail to
start. (LP: #1930359)
- d/p/gvdb-builder-Initialise-some-memory-to-zero-in-the-bloom-.patch
-- Matthew Ruffell Mon, 12 Jul 2021
15:56:16 +0100
** Changed in: glib2.0 (Ubuntu Focal)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1930359
Title:
glib2.0: Uninitialised memory is written to gschema.compiled, failure
to parse this file leads to gdm, gnome-shell failing to start
Status in GLib:
Unknown
Status in glib2.0 package in Ubuntu:
Fix Released
Status in glib2.0 source package in Focal:
Fix Released
Bug description:
[Impact]
A recent SRU of mutter 3.36.9-0ubuntu0.20.04.1 caused an outage for a
user with 300 VDIs running Focal, where GNOME applications would fail
to start, and if you reboot, gdm and gnome-shell both fail to start,
and you are left with a black screen and a blinking cursor.
After much investigation, mutter was not at fault. Instead, mutter-
common calls the libglib2.0-0 hook on upgrade:
Processing triggers for libglib2.0-0:amd64 (2.64.6-1~ubuntu20.04.3)
...
This in turn calls glib-compile-schemas to recompile the gsettings
gschema cache, from the files in /usr/share/glib-2.0/schemas/. The
result is a binary gschemas.compiled file, which is loaded by
libglib2.0 on every invocation of a GNOME application, or gdm or
gnome-shell to fetch application default settings.
Now, glib2.0 2.64.6-1~ubuntu20.04.3 in Focal has some non-
deterministic behaviour when calling glib-compile-schemas, causing
generated gschemas.compiled files to have differing contents on each
run:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 D0
3771 A4 DB
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 68
3771 A4 30
3772 55 56
The bytes on the left are from a corrupted gschemas.compiled provided
by an affected user. The changing bytes on the right are non-
deterministic.
I ran valgrind over glib-compile-schemas, and found that we are
writing to uninitialised memory.
https://paste.ubuntu.com/p/hvZccwdzxz/
What is happening is that a submodule of glib, gvdb, contains the
logic for serialising the gschema data structures, and when it
allocates a buffer to store the eventual gschemas.compiled file, it
does not initialise it.
When we populate the fields in the buffer, some bytes are never
overwritten, and these junk bytes find themselves written to
gschemas.compiled.
On boot, when gdm and gnome-shell attempt to parse and load this
corrupted gschemas.compiled file, it can't parse the junk bytes, and
raises and error, which propagates up to a breakpoint in glib logging,
but no debugger is present, so the kernel traps the breakpoint, and
terminates the library, and the calling application, e.g. gdm.
The result is that the user is left starting at a black screen with a
blinking pointer.
[Testcase]
On a Focal system, simply run valgrind over glib-compile-schemas:
# valgrind glib-compile-schemas /usr/share/glib-2.0/schemas
You will get output like this, with the warning "Syscall param
write(buf) points to uninitialised byte(s)":
https://paste.ubuntu.com/p/hvZccwdzxz/
If you happen to have a large amount of gschema overrides present on
your system, like my affected user does, you can save a copy of a
generated gschema.compiled to your home directory and bindiff it
against recompiles:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cp /usr/share/glib-2.0/schemas/gschema.compiled
/home/ubuntu/schemas/gschemas.compiled
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
If you install
[Desktop-packages] [Bug 1930359] Re: glib2.0: Uninitialised memory is written to gschema.compiled, failure to parse this file leads to gdm, gnome-shell failing to start
The autopkgtests worked after a retry
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1930359
Title:
glib2.0: Uninitialised memory is written to gschema.compiled, failure
to parse this file leads to gdm, gnome-shell failing to start
Status in GLib:
Unknown
Status in glib2.0 package in Ubuntu:
Fix Released
Status in glib2.0 source package in Focal:
Fix Committed
Bug description:
[Impact]
A recent SRU of mutter 3.36.9-0ubuntu0.20.04.1 caused an outage for a
user with 300 VDIs running Focal, where GNOME applications would fail
to start, and if you reboot, gdm and gnome-shell both fail to start,
and you are left with a black screen and a blinking cursor.
After much investigation, mutter was not at fault. Instead, mutter-
common calls the libglib2.0-0 hook on upgrade:
Processing triggers for libglib2.0-0:amd64 (2.64.6-1~ubuntu20.04.3)
...
This in turn calls glib-compile-schemas to recompile the gsettings
gschema cache, from the files in /usr/share/glib-2.0/schemas/. The
result is a binary gschemas.compiled file, which is loaded by
libglib2.0 on every invocation of a GNOME application, or gdm or
gnome-shell to fetch application default settings.
Now, glib2.0 2.64.6-1~ubuntu20.04.3 in Focal has some non-
deterministic behaviour when calling glib-compile-schemas, causing
generated gschemas.compiled files to have differing contents on each
run:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 D0
3771 A4 DB
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 68
3771 A4 30
3772 55 56
The bytes on the left are from a corrupted gschemas.compiled provided
by an affected user. The changing bytes on the right are non-
deterministic.
I ran valgrind over glib-compile-schemas, and found that we are
writing to uninitialised memory.
https://paste.ubuntu.com/p/hvZccwdzxz/
What is happening is that a submodule of glib, gvdb, contains the
logic for serialising the gschema data structures, and when it
allocates a buffer to store the eventual gschemas.compiled file, it
does not initialise it.
When we populate the fields in the buffer, some bytes are never
overwritten, and these junk bytes find themselves written to
gschemas.compiled.
On boot, when gdm and gnome-shell attempt to parse and load this
corrupted gschemas.compiled file, it can't parse the junk bytes, and
raises and error, which propagates up to a breakpoint in glib logging,
but no debugger is present, so the kernel traps the breakpoint, and
terminates the library, and the calling application, e.g. gdm.
The result is that the user is left starting at a black screen with a
blinking pointer.
[Testcase]
On a Focal system, simply run valgrind over glib-compile-schemas:
# valgrind glib-compile-schemas /usr/share/glib-2.0/schemas
You will get output like this, with the warning "Syscall param
write(buf) points to uninitialised byte(s)":
https://paste.ubuntu.com/p/hvZccwdzxz/
If you happen to have a large amount of gschema overrides present on
your system, like my affected user does, you can save a copy of a
generated gschema.compiled to your home directory and bindiff it
against recompiles:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cp /usr/share/glib-2.0/schemas/gschema.compiled
/home/ubuntu/schemas/gschemas.compiled
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
If you install the test package from the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf311791-test
When you run valgrind, it will report a clean run with no writing to
uninitialised buffers, and all invocations of glib-compile-schemas
will be deterministic, and generate the file same with the same sha256
hash every time. The unwritten bytes if you do a bindiff from before
and after will be all set to zero.
[Where problems can occur]
I am doubtful that any programs are relying on buggy non-deterministic
behaviour from random bytes found in uninitialised memory, so this
should be a
[Desktop-packages] [Bug 1930359] Re: glib2.0: Uninitialised memory is written to gschema.compiled, failure to parse this file leads to gdm, gnome-shell failing to start
Performing verification for Focal.
I will first reproduce the problem with glib2.0 2.64.6-1~ubuntu20.04.3
from -security with the libglib2.0-0 libglib2.0-bin libglib2.0-data
packages.
I deleted all existing schemas from /usr/share/glib-2.0/schemas and
replaced them with a set of schemas which reproduce the problem easily
from my customer.
$ cd /usr/share/glib-2.0/schemas/
$ sudo rm *
$ sudo cp ~/schemas/* .
The gsettings.compiled from the customer has been corrupted, and when I
reboot, gdm fails to start and I get a blank screen with a blinking
insertion pointer.
The sha256 of the customers corrupted gsettings.compiled is:
$ sudo openssl sha256 /usr/share/glib-2.0/schemas/gschemas.compiled
SHA256(/usr/share/glib-2.0/schemas/gschemas.compiled)=
2c98dc9a7fdbac858a8d5ca7e4dd813f16058a46dba2c54b5239cd8cdba5bb3e
When I ssh back in, and recompile the file:
$ sudo glib-compile-schemas /usr/share/glib-2.0/schemas
Error parsing key “logout” in schema
“org.gnome.settings-daemon.plugins.media-keys” as specified in override file
“/usr/share/glib-2.0/schemas/50_vmware_viewagent.gschema.override”: 0-22:can
not parse as value of type 'as'. Ignoring override for this key.
$ sudo openssl sha256 /usr/share/glib-2.0/schemas/gschemas.compiled
SHA256(/usr/share/glib-2.0/schemas/gschemas.compiled)=
78163b5fefbd6320ce0d355c9531bf657a4f4dc15f057d95ef144323cd56
The sha256 has changed. Doing a bindiff, I see:
$ sudo cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 4F
3771 A4 C2
We see two bytes different. These bytes are the uninitialised memory
this bug is about. When I reboot, gdm starts fine, but that is because
this time I got lucky and the parser for the gschema.compiled file
thinks 4F and C2 are okay. But there are combinations which aren't okay,
and will end up with a corrupted gschema.compiled file.
Re-compiling the file again:
$ sudo glib-compile-schemas /usr/share/glib-2.0/schemas
Error parsing key “logout” in schema
“org.gnome.settings-daemon.plugins.media-keys” as specified in override file
“/usr/share/glib-2.0/schemas/50_vmware_viewagent.gschema.override”: 0-22:can
not parse as value of type 'as'. Ignoring override for this key.
$ sudo openssl sha256 /usr/share/glib-2.0/schemas/gschemas.compiled
SHA256(/usr/share/glib-2.0/schemas/gschemas.compiled)=
460c70faca7afc26fa88a0e5918d312478e15f20ad84f4afaa5d17627a823e01
The sha256 changed, and if we bindiff, the bytes have changed:
$ sudo cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 A6
3771 A4 A1
If we run glib-compile-schemas through valgrind, it reports that we are
writing to uninitialised memory:
https://paste.ubuntu.com/p/sxrQtbswpw/
I then enabled -proposed and installed libglib2.0-0 libglib2.0-bin
libglib2.0-data version 2.64.6-1~ubuntu20.04.4.
Now, when I re-compile the gschemas.compiled file, the sha256 matches
every time, meaning no more non-deterministic behaviour caused by
writing unitialised memory to disk:
$ sudo glib-compile-schemas /usr/share/glib-2.0/schemas
Error parsing key “logout” in schema
“org.gnome.settings-daemon.plugins.media-keys” as specified in override file
“/usr/share/glib-2.0/schemas/50_vmware_viewagent.gschema.override”: 0-22:can
not parse as value of type 'as'. Ignoring override for this key.
$ sudo openssl sha256 /usr/share/glib-2.0/schemas/gschemas.compiled
SHA256(/usr/share/glib-2.0/schemas/gschemas.compiled)=
cd9132d18b596a304251cd1eb50b64aa6fd7511a312906f9a49e1975a319fbf1
$ sudo glib-compile-schemas /usr/share/glib-2.0/schemas
Error parsing key “logout” in schema
“org.gnome.settings-daemon.plugins.media-keys” as specified in override file
“/usr/share/glib-2.0/schemas/50_vmware_viewagent.gschema.override”: 0-22:can
not parse as value of type 'as'. Ignoring override for this key.
$ sudo openssl sha256 /usr/share/glib-2.0/schemas/gschemas.compiled
SHA256(/usr/share/glib-2.0/schemas/gschemas.compiled)=
cd9132d18b596a304251cd1eb50b64aa6fd7511a312906f9a49e1975a319fbf1
Doing a bindiff, I see the changed bytes from before are now all zeros,
which is what the patch initialises the buffer to:
$ sudo cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 00
3771 A4 00
3772 55 00
Doing a run through valgrind, we no longer get a report about writing to
uninitialised memory:
https://paste.ubuntu.com/p/z52DGZcdz3/
Rebooting, the VM comes up and GDM starts properly, so glib can parse
the gsettings.compiled file without any issues.
Wonderful. The problem is fixed by the package in -proposed, happy to
mark as verified.
** Tags removed: sts-sponsor verification-needed verification-needed-focal
** Tags added:
[Desktop-packages] [Bug 1930359] Re: glib2.0: Uninitialised memory is written to gschema.compiled, failure to parse this file leads to gdm, gnome-shell failing to start
Hello Matthew, or anyone else affected,
Accepted glib2.0 into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/glib2.0/2.64.6-1~ubuntu20.04.4 in a
few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.
Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!
N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.
** Changed in: glib2.0 (Ubuntu Focal)
Status: In Progress => Fix Committed
** Tags added: verification-needed verification-needed-focal
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1930359
Title:
glib2.0: Uninitialised memory is written to gschema.compiled, failure
to parse this file leads to gdm, gnome-shell failing to start
Status in GLib:
Unknown
Status in glib2.0 package in Ubuntu:
Fix Released
Status in glib2.0 source package in Focal:
Fix Committed
Bug description:
[Impact]
A recent SRU of mutter 3.36.9-0ubuntu0.20.04.1 caused an outage for a
user with 300 VDIs running Focal, where GNOME applications would fail
to start, and if you reboot, gdm and gnome-shell both fail to start,
and you are left with a black screen and a blinking cursor.
After much investigation, mutter was not at fault. Instead, mutter-
common calls the libglib2.0-0 hook on upgrade:
Processing triggers for libglib2.0-0:amd64 (2.64.6-1~ubuntu20.04.3)
...
This in turn calls glib-compile-schemas to recompile the gsettings
gschema cache, from the files in /usr/share/glib-2.0/schemas/. The
result is a binary gschemas.compiled file, which is loaded by
libglib2.0 on every invocation of a GNOME application, or gdm or
gnome-shell to fetch application default settings.
Now, glib2.0 2.64.6-1~ubuntu20.04.3 in Focal has some non-
deterministic behaviour when calling glib-compile-schemas, causing
generated gschemas.compiled files to have differing contents on each
run:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 D0
3771 A4 DB
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 68
3771 A4 30
3772 55 56
The bytes on the left are from a corrupted gschemas.compiled provided
by an affected user. The changing bytes on the right are non-
deterministic.
I ran valgrind over glib-compile-schemas, and found that we are
writing to uninitialised memory.
https://paste.ubuntu.com/p/hvZccwdzxz/
What is happening is that a submodule of glib, gvdb, contains the
logic for serialising the gschema data structures, and when it
allocates a buffer to store the eventual gschemas.compiled file, it
does not initialise it.
When we populate the fields in the buffer, some bytes are never
overwritten, and these junk bytes find themselves written to
gschemas.compiled.
On boot, when gdm and gnome-shell attempt to parse and load this
corrupted gschemas.compiled file, it can't parse the junk bytes, and
raises and error, which propagates up to a breakpoint in glib logging,
but no debugger is present, so the kernel traps the breakpoint, and
terminates the library, and the calling application, e.g. gdm.
The result is that the user is left starting at a black screen with a
blinking pointer.
[Testcase]
On a Focal system, simply run valgrind over glib-compile-schemas:
# valgrind glib-compile-schemas /usr/share/glib-2.0/schemas
You will get output like this, with the
[Desktop-packages] [Bug 1930359] Re: glib2.0: Uninitialised memory is written to gschema.compiled, failure to parse this file leads to gdm, gnome-shell failing to start
> Looks like both of us sponsored it for the queue. I'd appreciate
rejecting either one of them.
I pushed to the VCS[0] at the same time as sponsoring, so I'll reject
the other one which doesn't quite match up with it.
[0] https://salsa.debian.org/gnome-
team/glib/-/commits/ubuntu/2.64.6-1_ubuntu20.04.4/
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1930359
Title:
glib2.0: Uninitialised memory is written to gschema.compiled, failure
to parse this file leads to gdm, gnome-shell failing to start
Status in GLib:
Unknown
Status in glib2.0 package in Ubuntu:
Fix Released
Status in glib2.0 source package in Focal:
In Progress
Bug description:
[Impact]
A recent SRU of mutter 3.36.9-0ubuntu0.20.04.1 caused an outage for a
user with 300 VDIs running Focal, where GNOME applications would fail
to start, and if you reboot, gdm and gnome-shell both fail to start,
and you are left with a black screen and a blinking cursor.
After much investigation, mutter was not at fault. Instead, mutter-
common calls the libglib2.0-0 hook on upgrade:
Processing triggers for libglib2.0-0:amd64 (2.64.6-1~ubuntu20.04.3)
...
This in turn calls glib-compile-schemas to recompile the gsettings
gschema cache, from the files in /usr/share/glib-2.0/schemas/. The
result is a binary gschemas.compiled file, which is loaded by
libglib2.0 on every invocation of a GNOME application, or gdm or
gnome-shell to fetch application default settings.
Now, glib2.0 2.64.6-1~ubuntu20.04.3 in Focal has some non-
deterministic behaviour when calling glib-compile-schemas, causing
generated gschemas.compiled files to have differing contents on each
run:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 D0
3771 A4 DB
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 68
3771 A4 30
3772 55 56
The bytes on the left are from a corrupted gschemas.compiled provided
by an affected user. The changing bytes on the right are non-
deterministic.
I ran valgrind over glib-compile-schemas, and found that we are
writing to uninitialised memory.
https://paste.ubuntu.com/p/hvZccwdzxz/
What is happening is that a submodule of glib, gvdb, contains the
logic for serialising the gschema data structures, and when it
allocates a buffer to store the eventual gschemas.compiled file, it
does not initialise it.
When we populate the fields in the buffer, some bytes are never
overwritten, and these junk bytes find themselves written to
gschemas.compiled.
On boot, when gdm and gnome-shell attempt to parse and load this
corrupted gschemas.compiled file, it can't parse the junk bytes, and
raises and error, which propagates up to a breakpoint in glib logging,
but no debugger is present, so the kernel traps the breakpoint, and
terminates the library, and the calling application, e.g. gdm.
The result is that the user is left starting at a black screen with a
blinking pointer.
[Testcase]
On a Focal system, simply run valgrind over glib-compile-schemas:
# valgrind glib-compile-schemas /usr/share/glib-2.0/schemas
You will get output like this, with the warning "Syscall param
write(buf) points to uninitialised byte(s)":
https://paste.ubuntu.com/p/hvZccwdzxz/
If you happen to have a large amount of gschema overrides present on
your system, like my affected user does, you can save a copy of a
generated gschema.compiled to your home directory and bindiff it
against recompiles:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cp /usr/share/glib-2.0/schemas/gschema.compiled
/home/ubuntu/schemas/gschemas.compiled
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
If you install the test package from the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf311791-test
When you run valgrind, it will report a clean run with no writing to
uninitialised buffers, and all invocations of glib-compile-schemas
will be deterministic, and generate the file same with the same sha256
hash every time. The
[Desktop-packages] [Bug 1930359] Re: glib2.0: Uninitialised memory is written to gschema.compiled, failure to parse this file leads to gdm, gnome-shell failing to start
Thanks Iain. Looks like both of us sponsored it for the queue. I'd
appreciate rejecting either one of them.
Thanks!
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1930359
Title:
glib2.0: Uninitialised memory is written to gschema.compiled, failure
to parse this file leads to gdm, gnome-shell failing to start
Status in GLib:
Unknown
Status in glib2.0 package in Ubuntu:
Fix Released
Status in glib2.0 source package in Focal:
In Progress
Bug description:
[Impact]
A recent SRU of mutter 3.36.9-0ubuntu0.20.04.1 caused an outage for a
user with 300 VDIs running Focal, where GNOME applications would fail
to start, and if you reboot, gdm and gnome-shell both fail to start,
and you are left with a black screen and a blinking cursor.
After much investigation, mutter was not at fault. Instead, mutter-
common calls the libglib2.0-0 hook on upgrade:
Processing triggers for libglib2.0-0:amd64 (2.64.6-1~ubuntu20.04.3)
...
This in turn calls glib-compile-schemas to recompile the gsettings
gschema cache, from the files in /usr/share/glib-2.0/schemas/. The
result is a binary gschemas.compiled file, which is loaded by
libglib2.0 on every invocation of a GNOME application, or gdm or
gnome-shell to fetch application default settings.
Now, glib2.0 2.64.6-1~ubuntu20.04.3 in Focal has some non-
deterministic behaviour when calling glib-compile-schemas, causing
generated gschemas.compiled files to have differing contents on each
run:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 D0
3771 A4 DB
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 68
3771 A4 30
3772 55 56
The bytes on the left are from a corrupted gschemas.compiled provided
by an affected user. The changing bytes on the right are non-
deterministic.
I ran valgrind over glib-compile-schemas, and found that we are
writing to uninitialised memory.
https://paste.ubuntu.com/p/hvZccwdzxz/
What is happening is that a submodule of glib, gvdb, contains the
logic for serialising the gschema data structures, and when it
allocates a buffer to store the eventual gschemas.compiled file, it
does not initialise it.
When we populate the fields in the buffer, some bytes are never
overwritten, and these junk bytes find themselves written to
gschemas.compiled.
On boot, when gdm and gnome-shell attempt to parse and load this
corrupted gschemas.compiled file, it can't parse the junk bytes, and
raises and error, which propagates up to a breakpoint in glib logging,
but no debugger is present, so the kernel traps the breakpoint, and
terminates the library, and the calling application, e.g. gdm.
The result is that the user is left starting at a black screen with a
blinking pointer.
[Testcase]
On a Focal system, simply run valgrind over glib-compile-schemas:
# valgrind glib-compile-schemas /usr/share/glib-2.0/schemas
You will get output like this, with the warning "Syscall param
write(buf) points to uninitialised byte(s)":
https://paste.ubuntu.com/p/hvZccwdzxz/
If you happen to have a large amount of gschema overrides present on
your system, like my affected user does, you can save a copy of a
generated gschema.compiled to your home directory and bindiff it
against recompiles:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cp /usr/share/glib-2.0/schemas/gschema.compiled
/home/ubuntu/schemas/gschemas.compiled
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
If you install the test package from the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf311791-test
When you run valgrind, it will report a clean run with no writing to
uninitialised buffers, and all invocations of glib-compile-schemas
will be deterministic, and generate the file same with the same sha256
hash every time. The unwritten bytes if you do a bindiff from before
and after will be all set to zero.
[Where problems can occur]
I am doubtful that any programs are relying on buggy non-deterministic
[Desktop-packages] [Bug 1930359] Re: glib2.0: Uninitialised memory is written to gschema.compiled, failure to parse this file leads to gdm, gnome-shell failing to start
Thanks, sponsored to the queue
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1930359
Title:
glib2.0: Uninitialised memory is written to gschema.compiled, failure
to parse this file leads to gdm, gnome-shell failing to start
Status in GLib:
Unknown
Status in glib2.0 package in Ubuntu:
Fix Released
Status in glib2.0 source package in Focal:
In Progress
Bug description:
[Impact]
A recent SRU of mutter 3.36.9-0ubuntu0.20.04.1 caused an outage for a
user with 300 VDIs running Focal, where GNOME applications would fail
to start, and if you reboot, gdm and gnome-shell both fail to start,
and you are left with a black screen and a blinking cursor.
After much investigation, mutter was not at fault. Instead, mutter-
common calls the libglib2.0-0 hook on upgrade:
Processing triggers for libglib2.0-0:amd64 (2.64.6-1~ubuntu20.04.3)
...
This in turn calls glib-compile-schemas to recompile the gsettings
gschema cache, from the files in /usr/share/glib-2.0/schemas/. The
result is a binary gschemas.compiled file, which is loaded by
libglib2.0 on every invocation of a GNOME application, or gdm or
gnome-shell to fetch application default settings.
Now, glib2.0 2.64.6-1~ubuntu20.04.3 in Focal has some non-
deterministic behaviour when calling glib-compile-schemas, causing
generated gschemas.compiled files to have differing contents on each
run:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 D0
3771 A4 DB
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 68
3771 A4 30
3772 55 56
The bytes on the left are from a corrupted gschemas.compiled provided
by an affected user. The changing bytes on the right are non-
deterministic.
I ran valgrind over glib-compile-schemas, and found that we are
writing to uninitialised memory.
https://paste.ubuntu.com/p/hvZccwdzxz/
What is happening is that a submodule of glib, gvdb, contains the
logic for serialising the gschema data structures, and when it
allocates a buffer to store the eventual gschemas.compiled file, it
does not initialise it.
When we populate the fields in the buffer, some bytes are never
overwritten, and these junk bytes find themselves written to
gschemas.compiled.
On boot, when gdm and gnome-shell attempt to parse and load this
corrupted gschemas.compiled file, it can't parse the junk bytes, and
raises and error, which propagates up to a breakpoint in glib logging,
but no debugger is present, so the kernel traps the breakpoint, and
terminates the library, and the calling application, e.g. gdm.
The result is that the user is left starting at a black screen with a
blinking pointer.
[Testcase]
On a Focal system, simply run valgrind over glib-compile-schemas:
# valgrind glib-compile-schemas /usr/share/glib-2.0/schemas
You will get output like this, with the warning "Syscall param
write(buf) points to uninitialised byte(s)":
https://paste.ubuntu.com/p/hvZccwdzxz/
If you happen to have a large amount of gschema overrides present on
your system, like my affected user does, you can save a copy of a
generated gschema.compiled to your home directory and bindiff it
against recompiles:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cp /usr/share/glib-2.0/schemas/gschema.compiled
/home/ubuntu/schemas/gschemas.compiled
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
If you install the test package from the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf311791-test
When you run valgrind, it will report a clean run with no writing to
uninitialised buffers, and all invocations of glib-compile-schemas
will be deterministic, and generate the file same with the same sha256
hash every time. The unwritten bytes if you do a bindiff from before
and after will be all set to zero.
[Where problems can occur]
I am doubtful that any programs are relying on buggy non-deterministic
behaviour from random bytes found in uninitialised memory, so this
should be a relatively
[Desktop-packages] [Bug 1930359] Re: glib2.0: Uninitialised memory is written to gschema.compiled, failure to parse this file leads to gdm, gnome-shell failing to start
** Bug watch added: gitlab.gnome.org/GNOME/gvdb/-/issues #2
https://gitlab.gnome.org/GNOME/gvdb/-/issues/2
** Also affects: glib via
https://gitlab.gnome.org/GNOME/gvdb/-/issues/2
Importance: Unknown
Status: Unknown
** Tags added: fixed-in-2.65.0 fixed-upstream
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1930359
Title:
glib2.0: Uninitialised memory is written to gschema.compiled, failure
to parse this file leads to gdm, gnome-shell failing to start
Status in GLib:
Unknown
Status in glib2.0 package in Ubuntu:
Fix Released
Status in glib2.0 source package in Focal:
In Progress
Bug description:
[Impact]
A recent SRU of mutter 3.36.9-0ubuntu0.20.04.1 caused an outage for a
user with 300 VDIs running Focal, where GNOME applications would fail
to start, and if you reboot, gdm and gnome-shell both fail to start,
and you are left with a black screen and a blinking cursor.
After much investigation, mutter was not at fault. Instead, mutter-
common calls the libglib2.0-0 hook on upgrade:
Processing triggers for libglib2.0-0:amd64 (2.64.6-1~ubuntu20.04.3)
...
This in turn calls glib-compile-schemas to recompile the gsettings
gschema cache, from the files in /usr/share/glib-2.0/schemas/. The
result is a binary gschemas.compiled file, which is loaded by
libglib2.0 on every invocation of a GNOME application, or gdm or
gnome-shell to fetch application default settings.
Now, glib2.0 2.64.6-1~ubuntu20.04.3 in Focal has some non-
deterministic behaviour when calling glib-compile-schemas, causing
generated gschemas.compiled files to have differing contents on each
run:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 D0
3771 A4 DB
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 68
3771 A4 30
3772 55 56
The bytes on the left are from a corrupted gschemas.compiled provided
by an affected user. The changing bytes on the right are non-
deterministic.
I ran valgrind over glib-compile-schemas, and found that we are
writing to uninitialised memory.
https://paste.ubuntu.com/p/hvZccwdzxz/
What is happening is that a submodule of glib, gvdb, contains the
logic for serialising the gschema data structures, and when it
allocates a buffer to store the eventual gschemas.compiled file, it
does not initialise it.
When we populate the fields in the buffer, some bytes are never
overwritten, and these junk bytes find themselves written to
gschemas.compiled.
On boot, when gdm and gnome-shell attempt to parse and load this
corrupted gschemas.compiled file, it can't parse the junk bytes, and
raises and error, which propagates up to a breakpoint in glib logging,
but no debugger is present, so the kernel traps the breakpoint, and
terminates the library, and the calling application, e.g. gdm.
The result is that the user is left starting at a black screen with a
blinking pointer.
[Testcase]
On a Focal system, simply run valgrind over glib-compile-schemas:
# valgrind glib-compile-schemas /usr/share/glib-2.0/schemas
You will get output like this, with the warning "Syscall param
write(buf) points to uninitialised byte(s)":
https://paste.ubuntu.com/p/hvZccwdzxz/
If you happen to have a large amount of gschema overrides present on
your system, like my affected user does, you can save a copy of a
generated gschema.compiled to your home directory and bindiff it
against recompiles:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cp /usr/share/glib-2.0/schemas/gschema.compiled
/home/ubuntu/schemas/gschemas.compiled
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
If you install the test package from the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf311791-test
When you run valgrind, it will report a clean run with no writing to
uninitialised buffers, and all invocations of glib-compile-schemas
will be deterministic, and generate the file same with the same sha256
hash every time. The unwritten bytes if you do a
[Desktop-packages] [Bug 1930359] Re: glib2.0: Uninitialised memory is written to gschema.compiled, failure to parse this file leads to gdm, gnome-shell failing to start
Attached is a debdiff for glib2.0 on Focal which fixes this problem.
** Patch added: "Debdiff for glib2.0 for Focal"
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1930359/+attachment/5510466/+files/lp1930359_focal.debdiff
** Tags removed: regression-update
** Tags added: sts-sponsor
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1930359
Title:
glib2.0: Uninitialised memory is written to gschema.compiled, failure
to parse this file leads to gdm, gnome-shell failing to start
Status in glib2.0 package in Ubuntu:
Fix Released
Status in glib2.0 source package in Focal:
In Progress
Bug description:
[Impact]
A recent SRU of mutter 3.36.9-0ubuntu0.20.04.1 caused an outage for a
user with 300 VDIs running Focal, where GNOME applications would fail
to start, and if you reboot, gdm and gnome-shell both fail to start,
and you are left with a black screen and a blinking cursor.
After much investigation, mutter was not at fault. Instead, mutter-
common calls the libglib2.0-0 hook on upgrade:
Processing triggers for libglib2.0-0:amd64 (2.64.6-1~ubuntu20.04.3)
...
This in turn calls glib-compile-schemas to recompile the gsettings
gschema cache, from the files in /usr/share/glib-2.0/schemas/. The
result is a binary gschemas.compiled file, which is loaded by
libglib2.0 on every invocation of a GNOME application, or gdm or
gnome-shell to fetch application default settings.
Now, glib2.0 2.64.6-1~ubuntu20.04.3 in Focal has some non-
deterministic behaviour when calling glib-compile-schemas, causing
generated gschemas.compiled files to have differing contents on each
run:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 D0
3771 A4 DB
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 68
3771 A4 30
3772 55 56
The bytes on the left are from a corrupted gschemas.compiled provided
by an affected user. The changing bytes on the right are non-
deterministic.
I ran valgrind over glib-compile-schemas, and found that we are
writing to uninitialised memory.
https://paste.ubuntu.com/p/hvZccwdzxz/
What is happening is that a submodule of glib, gvdb, contains the
logic for serialising the gschema data structures, and when it
allocates a buffer to store the eventual gschemas.compiled file, it
does not initialise it.
When we populate the fields in the buffer, some bytes are never
overwritten, and these junk bytes find themselves written to
gschemas.compiled.
On boot, when gdm and gnome-shell attempt to parse and load this
corrupted gschemas.compiled file, it can't parse the junk bytes, and
raises and error, which propagates up to a breakpoint in glib logging,
but no debugger is present, so the kernel traps the breakpoint, and
terminates the library, and the calling application, e.g. gdm.
The result is that the user is left starting at a black screen with a
blinking pointer.
[Testcase]
On a Focal system, simply run valgrind over glib-compile-schemas:
# valgrind glib-compile-schemas /usr/share/glib-2.0/schemas
You will get output like this, with the warning "Syscall param
write(buf) points to uninitialised byte(s)":
https://paste.ubuntu.com/p/hvZccwdzxz/
If you happen to have a large amount of gschema overrides present on
your system, like my affected user does, you can save a copy of a
generated gschema.compiled to your home directory and bindiff it
against recompiles:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cp /usr/share/glib-2.0/schemas/gschema.compiled
/home/ubuntu/schemas/gschemas.compiled
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
If you install the test package from the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf311791-test
When you run valgrind, it will report a clean run with no writing to
uninitialised buffers, and all invocations of glib-compile-schemas
will be deterministic, and generate the file same with the same sha256
hash every time. The unwritten bytes if you do a bindiff from
