python-apt crashes if objects of one cache are passed to depcache belonging to another cache
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
python-apt (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Trusty |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
unattended-upgrades (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Trusty |
Won't Fix
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
Some applications, like unattended-upgrades or update-manager, reopen the apt cache. They also keep around old apt.Package objects however, and operate on them after reopening. Under the hood, this means that apt_pkg.Package objects belonging to an old cache are passed to a new cache.
APT relies on the ID of the package (it's position in the cache) for it's operation. So if a package has ID 0 in the old cache, and a different package has ID 0 in the new cache, performing operations on the old package would perform it on the new package. If the old package's ID is out of bounds in the new cache, the behavior is undefined - it's an out of bounds array access.
[Test case]
The attached test case has a list of packages 0-9, a-z; stores the package "z" into a variable, then reopens the cache. It then marks z for deletion. This either segfaults or does nothing; when it should mark z for deletion.
More test cases like this are in the autopkgtest.
[Regression potential]
The initial fix introduced bug 1780099, there might be similar bugs lurking. However, these bugs would have been undefined behavior before and might have caused segmentation faults or did the wrong thing. It seems likely that any regression cannot possibly be worse than the current state.
[Other info]
The xenial SRU also includes the change "python/tag.cc: Fix invalid read in TagFileNext". We don't have any specific verification for it, as we just saw weird crashes on the error tracker, and this seemed like the culprit. We released bionic with it, and it seems fine. The fix is fairly obvious: We were copying the char array "Start" which was not nul terminated in an odd way, without using the lenght.
[Original bug report]
The Ubuntu Error Tracker has been receiving reports about a problem regarding unattended-
If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://
Changed in unattended-upgrades (Ubuntu): | |
status: | New → Invalid |
tags: | added: id-5a8ef5f4d8bb16ec254dc10f |
Changed in python-apt (Ubuntu Bionic): | |
status: | Confirmed → In Progress |
Changed in unattended-upgrades (Ubuntu Bionic): | |
status: | Triaged → In Progress |
Changed in python-apt (Ubuntu Bionic): | |
status: | In Progress → Fix Committed |
Changed in unattended-upgrades (Ubuntu Bionic): | |
status: | In Progress → Fix Committed |
description: | updated |
description: | updated |
Changed in python-apt (Ubuntu Xenial): | |
status: | New → Triaged |
Changed in unattended-upgrades (Ubuntu Trusty): | |
status: | New → Won't Fix |
Changed in unattended-upgrades (Ubuntu Xenial): | |
status: | New → Won't Fix |
summary: |
- /usr/bin/unattended- - upgrade:11:__GI___libc_free:operator:__gnu_cxx::new_allocator:std::allocator_traits:std::__cxx11::basic_string + python-apt crashes if objects of one cache are passed to depcache + belonging to another cache |
description: | updated |
I'm not sure what's going on here. Maybe it's deleting the cachefile twice somehow. It's just straight-forward destructors. Very odd.