This bug was fixed in the package klibc - 2.0.6-1ubuntu3
---
klibc (2.0.6-1ubuntu3) eoan; urgency=medium
* Pull upstream fixes for losetup issues raised with gcc-9 (LP: #1850184):
- loop-header.patch: Switch to using the kernel's UAPI exported loop.h
- loop-fixes.patch: Fix
(eoan-amd64)root@nosferatu:~# apt-get install klibc-utils=2.0.6-1ubuntu2
libklibc=2.0.6-1ubuntu2
(eoan-amd64)root@nosferatu:~# /sbin/losetup -vf
/dev/loop6
(eoan-amd64)root@nosferatu:~# /usr/lib/klibc/bin/losetup -vf
Loop device is /dev/loop6
loop: can't get info on device /dev/loop6: No such devi
Hello Balint, or anyone else affected,
Accepted klibc into eoan-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/klibc/2.0.6-1ubuntu3
in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ub
This bug was fixed in the package klibc - 2.0.7-1ubuntu4
---
klibc (2.0.7-1ubuntu4) focal; urgency=medium
* Fix losetup, by switching to kernel uapi header, instead of buggy
klibc one. LP: #1850184
-- Dimitri John Ledkov Thu, 07 Nov 2019 01:08:13
+
** Changed in: klibc
Yeah, I saw the mail; much better. I fixed one of these in dietlibc the
other day…
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1850184
Title:
losetup -f broken in 2.0.6-1ubuntu2
To manage notific
We found the issue -- I think xnox is going to report it via proper
channels. But basically it's this:
sizeof(dev_t) = 4 sizeof(__kernel_old_dev_t) = 8
This makes the kernel's loop_info 8 bytes bigger than klibc's and so the
kernel is writing past the end of the loopinfo on the stack, which unti
How is this even a fix?
Also, does this affect other applications built against klibc?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1850184
Title:
losetup -f broken in 2.0.6-1ubuntu2
To manage no
** No longer affects: gcc-9 (Ubuntu)
** No longer affects: gcc-9 (Ubuntu Eoan)
** No longer affects: gcc-9 (Ubuntu Focal)
** No longer affects: linux (Ubuntu Focal)
** No longer affects: linux (Ubuntu Eoan)
** No longer affects: linux (Ubuntu)
--
You received this bug notification because yo
** Changed in: klibc (Ubuntu Focal)
Status: Fix Released => Confirmed
** Changed in: klibc (Ubuntu Eoan)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1850184
T
This is my replacement "minimized" losetup.c that exhibits the problem.
Simply, drop this into klibc sources
and run:
./debian/rules build; sudo ./usr/utils/static/losetup
1 Argc before find_unused_loop_devices()
0 Argc after find_unused_loop_devices()
Argc values before and after did not match.
This bug was fixed in the package klibc - 2.0.7-1ubuntu1
---
klibc (2.0.7-1ubuntu1) focal; urgency=low
* Merge from Debian unstable. Remaining changes:
* Fix FTBFS on eoan and later with new gcc
- cf-protection.patch: Disable cf-protection for syscalls stub.
* save-arg
** Tags added: patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1850184
Title:
losetup -f broken in 2.0.6-1ubuntu2
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu
Ah-ha. If loop0 is in use, then the test-case appropriately fails in
both unstable and eoan, which is comforting, as I didn't look forward to
figuring out why this works in Debian (it doesn't).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
** Description changed:
[Impact]
- * sudo /usr/lib/klibc/bin/losetup -vf, which appears to be missbuilt, as
main(argc) is reset to zero, after ioctl() operations in a function call, quite
unexpectadly.
-
+ * sudo /usr/lib/klibc/bin/losetup -vf, which appears to be missbuilt,
+ as main(a
The testcase here doesn't seem to be working (or, rather, failing) for
me, which makes it harder to investigate this. It passes on both sid
and eoan for me:
(sid-amd64)root@nosferatu:~# dpkg -l \*klibc\*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Hal
** Description changed:
+ [Impact]
+
+ * sudo /usr/lib/klibc/bin/losetup -vf, which appears to be missbuilt, as
main(argc) is reset to zero, after ioctl() operations in a function call, quite
unexpectadly.
+
+ [Test Case]
+
+ * sudo /usr/lib/klibc/bin/losetup -vf
+
+should not fail
** Patch added: "save-argc.patch"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1850184/+attachment/5301773/+files/save-argc.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1850184
Titl
So, I'm not sure if this is a kernel headers/assembly bug (as ioctl is
used from there), gcc-9 bug, or the combination of the two.
I'm going to save argc, and use a saved copy for now, but this needs
deeper analysis. This sounds like a retpoline mitigation.
** Also affects: klibc (Ubuntu Focal)
Fun: this works with 2.0.7-1 built with gcc-9 in Debian.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1850184
Title:
losetup -f broken in 2.0.6-1ubuntu2
To manage notifications about this bug go t
so calling an ioctl seems to clear the global argc in klibc built with
gcc-9
163 if(ioctl (fd, LOOP_GET_STATUS,
&loopinfo) == 0)
(gdb) bt
#0 find_unused_loop_device () at usr/utils/losetup.c:163
#1 0x00401135 in main (argc=2, argv=0x7fffe6
device = find_unused_loop_device();
if (device == NULL)
return -1;
if (verbose)
printf("Loop device is %s\n", device);
if (argc == optind) {
printf("%s\n", device);
return 0;
}
file = argv[optind];
Somehow... argc == optind condition is false, and instead of exiting
Rebuilding with gcc-8 => losetup works
Rebuilding with gcc-9 => losetup does not work
Rebuilding with gcc-9 & -fcf-protection=none & -fno-stack-clash-protection does
not work (and double checked that there are no gcc invocations in the build log
without those two options set)
--
You received th
22 matches
Mail list logo
