Re: CVE-2026-11460 - security flaw in serialization

Robert Ramey via Boost <[email protected]> Tue, 23 Jun 2026 10:40:54 -0700
Newsgroups gmane.comp.lib.boost.devel
Message-ID <[email protected]>
On 6/23/26 9:38 AM, Andrey Semashev via Boost wrote:
> On 23 Jun 2026 18:55, Robert Ramey via Boost wrote:
>> On 6/23/26 2:23 AM, Joaquin M López Muñoz via Boost wrote:
>>
>> I believe that there is no possible undefined for loading archives which
>> have been saved in the same format as that loaded.  The only scenario I
>> could think of where this could occur would be:
>>
>> a) There is an error in the usage of the library in that the user code
>> implementing the "saving" of an archive is not consistent with the code
>> implementing the "loading" of tthat archive.
> 

In general a the library cannot always detect when a user uses it in an 
incorrect manner. Perhaps it does sometimes - I don't know.

> Could a) be the case, for example, if the archive being loaded was saved
> by an older or different version of the program? In particular, if the
> set of data or types of data that was saved into the archive is
> different from what is expected by the loader? Does Boost.Serialization
> report an error in this case? Is the loader application able to tell
> that this mismatch has happened?

The boost serialization library includes a provision for versioning 
archives.  Each time the serialization format is changed the version 
number should be incremented. Each time an archive is loaded, the 
original version is available and can be compared against the current 
version.  So provision can/should be made to include conditional code to 
read previous versions.  This is well known and commonly done and I 
believe documented in the reference documentation.

No code which follows this procedure should ever suffer undefined behavior.

I can imagine some rare cases where there might still be a problem.  One 
that comes to mind is were one creates an archive on a 32 bit machine 
that stores an integer greater than 2^16 then tries to load it to a 16 
bit machine.  If one had nothing else to do, he could comb trough and 
detect such cases.  it's not that easy as they are really ununusual and 
as far as I know, there have been no reported problems of this nature. 
So it would be hard to know if one found all the pathalogical cases.

Robert Ramey

> 
> _______________________________________________
> Boost mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
> Archived at: https://lists.boost.org/archives/list/[email protected]/message/SH3XR22NWW5WGJAJN2N6CP3FVOZBFSJZ/


_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/TB7VLAP2B44EERIS5GFP4CSFCS4XULVN/