Bug 2256624 (CVE-2024-0217) - CVE-2024-0217 PackageKitd: Use-After-Free in Idle Function Callback
Summary: CVE-2024-0217 PackageKitd: Use-After-Free in Idle Function Callback
Keywords:
Status: NEW
Alias: CVE-2024-0217
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 2260042
Blocks: 2256627
TreeView+ depends on / blocked
 
Reported: 2024-01-03 13:18 UTC by Avinash Hanwate
Modified: 2024-02-23 03:05 UTC (History)
5 users (show)

Fixed In Version: PackageKit 1.2.7
Doc Type: ---
Doc Text:
A use-after-free flaw was found in PackageKitd. In some conditions, the order of cleanup mechanics for a transaction could be impacted. As a result, some memory access could occur on memory regions that were previously freed. Once freed, a memory region can be reused for other allocations and any previously stored data in this memory region is considered lost.
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description Avinash Hanwate 2024-01-03 13:18:35 UTC
PackageKit relies on “transactions” as a work unit to wrap package manager actions, these transactions are created by the user and freed when no longer in use or when a terminal error is emitted.
It was observed that under some conditions, the order of cleanup mechanics for a transaction could be impacted. As a result, some memory accesses could occur on memory regions that were previously freed. Once freed, a memory region can be reused for other allocations and any previously stored data in this memory region is considered lost. Usage of memory after it is cleaned is named Use-After-Free (UAF).
The most reliable way a transaction can be made to be cleaned whilst still running is by having a task for a package backend (dnf in our case) and simultaneously causing an error or successful termination of another task for that same transaction.

Comment 2 Salvatore Bonaccorso 2024-01-04 19:27:12 UTC
Can you reference the upstream change from v1.2.7 which addresses this issue?

Comment 3 Pedro Sampaio 2024-01-05 17:34:45 UTC
In reply to comment #2:
> Can you reference the upstream change from v1.2.7 which addresses this issue?

Although this is not a direct fix for the issue, this commit is believed to reduce impact in version 1.2.7 onward:

https://github.com/PackageKit/PackageKit/commit/64278c9127e3333342b56ead99556161f7e86f79

Comment 4 Salvatore Bonaccorso 2024-01-05 17:54:42 UTC
(In reply to Pedro Sampaio from comment #3)
> In reply to comment #2:
> > Can you reference the upstream change from v1.2.7 which addresses this issue?
> 
> Although this is not a direct fix for the issue, this commit is believed to
> reduce impact in version 1.2.7 onward:
> 
> https://github.com/PackageKit/PackageKit/commit/
> 64278c9127e3333342b56ead99556161f7e86f79

Thank you Pedro!

Comment 5 Sandipan Roy 2024-01-24 08:19:12 UTC
Created PackageKit tracking bugs for this issue:

Affects: fedora-all [bug 2260042]

Comment 6 Neal Gompa 2024-02-20 23:43:19 UTC
I am confused what is going on here? There doesn't seem to have been any upstream engagement about this CVE and neither I nor Matthias Klumpp have any idea what we're supposed to do here.

Comment 7 Pedro Sampaio 2024-02-22 14:45:35 UTC
In reply to comment #6:
> I am confused what is going on here? There doesn't seem to have been any
> upstream engagement about this CVE and neither I nor Matthias Klumpp have
> any idea what we're supposed to do here.

I think you already did, here:

https://github.com/PackageKit/PackageKit/pull/706

Comment 8 Matthias Klumpp 2024-02-23 03:05:31 UTC
(In reply to Pedro Sampaio from comment #7)
> In reply to comment #6:
> > I am confused what is going on here? There doesn't seem to have been any
> > upstream engagement about this CVE and neither I nor Matthias Klumpp have
> > any idea what we're supposed to do here.
> 
> I think you already did, here:
> 
> https://github.com/PackageKit/PackageKit/pull/706

That PR fixed an overflow error and not a use-after-free problem in a codepath unrelated to transaction lifecycle management.
It's a bug for sure, but I don't see the connection to this issue.


Note You need to log in before you can comment on or make changes to this bug.