Commit d56c728
committed
menu/ozone: fix three heap-safety issues found during an audit pass
Three issues found during a focused audit of menu/drivers/ozone.c.
The first is a latent double-free in the deep-copy helper that the
struct's own comment warned about; the second is a dangling-pointer
window during teardown across three sites; the third is a dead heap
allocation on every main-menu init. Same audit class as the recent
xmb pass (commit 9a27e66) since ozone shares much of its data-flow
shape with xmb.
* ozone_copy_node: latent double-free of console_name
(menu/drivers/ozone.c)
ozone_node has a comment above its definition saying
/* If you change this struct, also
change ozone_alloc_node and
ozone_copy_node */
ozone_alloc_node was kept in sync when console_name was added,
ozone_copy_node was not. ozone_copy_node does
*new_node = *old_node;
new_node->fullpath = old_node->fullpath
? strdup(old_node->fullpath) : NULL;
-- bitwise-copying every pointer field including console_name,
then deep-copying only fullpath. When either the source or the
copy is later passed to ozone_free_node, the free(node->
console_name) at the top of that function frees the same buffer
twice.
The bug is latent today: console_name is only populated on
horizontal_list nodes (sidebar playlist tabs), and the only
caller of ozone_copy_node is ozone_list_deep_copy, which copies
the vertical selection_buf into selection_buf_old for the
scroll-transition cache. Vertical entries don't carry a
console_name, so no double-free actually fires from current
call sites. But the precondition is unenforced -- any future
feature that copies a horizontal node (or even adds a second
string field to ozone_node and forgets the same step) re-opens
the bug. Mirror fullpath's strdup-or-NULL pattern.
* playlist_db_node_map freed after the nodes it borrows from
(menu/drivers/ozone.c)
Same shape as the xmb fix in 9a27e66. The map's values are
non-owning ozone_node_t* pointers into ozone->horizontal_list[i].
userdata, populated in ozone_context_reset_horizontal_list. In
ozone_refresh_horizontal_list, the ozone_init error path, and
ozone_free, the order was: free nodes via ozone_free_list_nodes,
then RHMAP_FREE the map. Between those two calls the map holds
dangling pointers.
No re-entry path I could trace would actually read the map during
that window today, but the invariant isn't enforced and the fix
is a one-line reorder per site. Free the map first at all three.
* ozone_menu_init_list: dead heap allocation
(menu/drivers/ozone.c)
info.exts = strldup("lpl", sizeof("lpl")) is allocated on every
main-menu init. DISPLAYLIST_MAIN_MENU never reads info->exts
(only directory-scanning displaylists like
DISPLAYLIST_DATABASE_PLAYLISTS_HORIZONTAL do, where the same
call legitimately filters .lpl files); the buffer is allocated,
never read, then freed by menu_displaylist_info_free. Almost
certainly copy-pasted from ozone_init_horizontal_list at line
~5046, same as the xmb instance fixed in 9a27e66. Drop it.1 parent 9a27e66 commit d56c728
1 file changed
Lines changed: 25 additions & 4 deletions
File tree
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
4632 | 4632 | | |
4633 | 4633 | | |
4634 | 4634 | | |
| 4635 | + | |
| 4636 | + | |
| 4637 | + | |
| 4638 | + | |
| 4639 | + | |
| 4640 | + | |
| 4641 | + | |
| 4642 | + | |
| 4643 | + | |
| 4644 | + | |
| 4645 | + | |
4635 | 4646 | | |
4636 | 4647 | | |
4637 | 4648 | | |
| 4649 | + | |
| 4650 | + | |
| 4651 | + | |
4638 | 4652 | | |
4639 | 4653 | | |
4640 | 4654 | | |
| |||
5254 | 5268 | | |
5255 | 5269 | | |
5256 | 5270 | | |
| 5271 | + | |
| 5272 | + | |
| 5273 | + | |
| 5274 | + | |
| 5275 | + | |
5257 | 5276 | | |
5258 | 5277 | | |
5259 | | - | |
5260 | 5278 | | |
5261 | 5279 | | |
5262 | 5280 | | |
| |||
9413 | 9431 | | |
9414 | 9432 | | |
9415 | 9433 | | |
| 9434 | + | |
| 9435 | + | |
| 9436 | + | |
9416 | 9437 | | |
9417 | 9438 | | |
9418 | 9439 | | |
9419 | 9440 | | |
9420 | | - | |
9421 | 9441 | | |
9422 | 9442 | | |
9423 | 9443 | | |
| |||
9444 | 9464 | | |
9445 | 9465 | | |
9446 | 9466 | | |
| 9467 | + | |
| 9468 | + | |
| 9469 | + | |
9447 | 9470 | | |
9448 | 9471 | | |
9449 | 9472 | | |
9450 | 9473 | | |
9451 | | - | |
9452 | 9474 | | |
9453 | 9475 | | |
9454 | 9476 | | |
| |||
13033 | 13055 | | |
13034 | 13056 | | |
13035 | 13057 | | |
13036 | | - | |
13037 | 13058 | | |
13038 | 13059 | | |
13039 | 13060 | | |
| |||
0 commit comments