Thread unsafe access to internal linked list, breaks Origin games in Wine
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
xlibs |
Unknown
|
Medium
|
|||
libx11 (Ubuntu) |
Triaged
|
Medium
|
Unassigned |
Bug Description
In file src/xlibi18n/
static XlcConverterList conv_list = NULL;
Which is then modified by _XlcSetConverter and get_converter in a non thread-safe manner. Inside get_converter the list is reorderder to increase the efficiency of looking up the same element the next time, but this is especially dangerous since a seemingly read-only method is actually modifying the data.
Modifying the list in such thread unsafe manner does case the list to become garbled in some workloads and causes infinite loops when the get_converter is invoked. The solution I suggest is to add a mutex or spinlock around accesses to the linked list, I would it myself but I'm not sure about what is the usual mutex implementation for this project.
Changed in xlibs: | |
importance: | Unknown → Medium |
status: | Unknown → Confirmed |
Changed in libx11 (Ubuntu): | |
assignee: | nobody → Canonical X.org (canonical-x) |
status: | Confirmed → Triaged |
importance: | Undecided → High |
Changed in xlibs: | |
status: | Confirmed → Unknown |
In file src/xlibi18n/ lcConv. c the following linked list head is defined
static XlcConverterList conv_list = NULL;
Which is then modified by _XlcSetConverter and get_converter in a non thread-safe manner. Inside get_converter the list is reorderder to increase the efficiency of looking up the same element the next time, but this is especially dangerous since a seemingly read-only method is actually modifying the data.
Modifying the list in such thread unsafe manner does case the list to become garbled in some workloads and causes infinite loops when the get_converter is invoked. The solution I suggest is to add a mutex or spinlock around accesses to the linked list, I would it myself but I'm not sure about what is the usual mutex implementation for this project.