CVE-2026-43489

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> liveupdate: luo_file: remember retrieve() status<br /> <br /> LUO keeps track of successful retrieve attempts on a LUO file. It does so<br /> to avoid multiple retrievals of the same file. Multiple retrievals cause<br /> problems because once the file is retrieved, the serialized data<br /> structures are likely freed and the file is likely in a very different<br /> state from what the code expects.<br /> <br /> The retrieve boolean in struct luo_file keeps track of this, and is passed<br /> to the finish callback so it knows what work was already done and what it<br /> has left to do.<br /> <br /> All this works well when retrieve succeeds. When it fails,<br /> luo_retrieve_file() returns the error immediately, without ever storing<br /> anywhere that a retrieve was attempted or what its error code was. This<br /> results in an errored LIVEUPDATE_SESSION_RETRIEVE_FD ioctl to userspace,<br /> but nothing prevents it from trying this again.<br /> <br /> The retry is problematic for much of the same reasons listed above. The<br /> file is likely in a very different state than what the retrieve logic<br /> normally expects, and it might even have freed some serialization data<br /> structures. Attempting to access them or free them again is going to<br /> break things.<br /> <br /> For example, if memfd managed to restore 8 of its 10 folios, but fails on<br /> the 9th, a subsequent retrieve attempt will try to call<br /> kho_restore_folio() on the first folio again, and that will fail with a<br /> warning since it is an invalid operation.<br /> <br /> Apart from the retry, finish() also breaks. Since on failure the<br /> retrieved bool in luo_file is never touched, the finish() call on session<br /> close will tell the file handler that retrieve was never attempted, and it<br /> will try to access or free the data structures that might not exist, much<br /> in the same way as the retry attempt.<br /> <br /> There is no sane way of attempting the retrieve again. Remember the error<br /> retrieve returned and directly return it on a retry. Also pass this<br /> status code to finish() so it can make the right decision on the work it<br /> needs to do.<br /> <br /> This is done by changing the bool to an integer. A value of 0 means<br /> retrieve was never attempted, a positive value means it succeeded, and a<br /> negative value means it failed and the error code is the value.