On Sat, 19 Sept 2026 at 09:15, Kristian Nielsen <[email protected]> wrote: > > Gordan Bobic via discuss <[email protected]> writes: > > > Hi, I've been working on mapping CVE fixes in 10.6.x for the purpose > > of backporting the fixes recently. These two in 10.6.28 have me a > > little suspicious: > > CVE-2026-60585 > > CVE-2026-60184 > > From the CVE description, these both concern the case where the attacker is > able to craft arbitrary replication events and cause a slave server to > execute them.
Yes, that was my conclusion, too. But having reviewed all of the commits between 10.6.27 and 10.6.28 in the replication subsystem, and having excluded the commits I identified as matching other CVEs that were fixed in 10.6.28, those two CVEs don't seem to be mappable to any commits that landed in 10.6.28. > The report mentions the ability to fully take over the server and/or > bringing it down until restarted. However, this capability is inherent in > the ability to control the replication stream. The slave must replicate > _all_ changes done on the master, including ie. creating a custom root > account or basically anything that could happen on the master, so this is > already "full takeover" by the nature of what replication means. Here is what I have for the 10.6.28 mapping: CVE-2026-61081 (MDEV-39622 revert) CVE-2026-60747, CVE-2026-47023 (MDEV-39689 + test update) CVE-2026-60331 (MDEV-40298) MDEV-40470 (no CVE) The ones in 10.11.19 that are missing in 10.6.28 that seem relevant are these: MDEV-40365 e491a1e8804 OOB read on malformed Format_description_log_event (part 1; creates mysql-test/suite/binlog/t/fdle_overflow.test + .result) MDEV-40366 c61b1a2ef7c OOB read on malformed Format_description_log_event (part 2; modifies the fdle test files created by 40365) MDEV-40647 52a2bc27ccc OOB read in IO thread when FDE does not support Rotate events (modifies fdle test files; adds rpl_rotate_ev_overflow test) MDEV-40643 ebb48286fb9 Corrupt/truncated Heartbeat Log Event can crash slave MDEV-40492 10313100b97 Oversized Fake Rotate Event can crash slave MDEV-40648 9e4948c2cf9 (+ test fix edef9f2fd35) Declared-size vs actual-size mismatch → hidden second event applied from surplus bytes; replica data unverifiable against master's binlog. Strongest candidate for CVE-2026-60585 (takeover). MDEV-40644 8216ea97598 SQL-thread overflow on malformed Table_map (overlong db/table name) MDEV-40646 080480c52d1 Undersized Table_map metadata can crash slave MDEV-39762 f17a3ea6009 Slave overflow on malformed Query_compressed_log_event MDEV-39485 cd51639e4a5 Heap-buffer-overflow / memory disclosure in v2 Rows_log_event with truncated extra data MDEV-40645 7d73a695267 Slave crash on malformed User_var_log_event MDEV-40648 edef9f2fd35 Fix rpl.rpl_corruption This is why I am suspecting that the fix in 10.6.28 is either incomplete or missing for CVE-2026-60585 CVE-2026-60184 > The only extra capability I have seen discussed is if the system is relying > on secure_file_priv for containerising an untrusted MariaDB server on a > trusted host, due to RCE. It is not mentioned in the two CVEs that this > would be the case, and as you omitted the specific commits I cannot tell if > it would apply. > > My recommendation would be that this recent stream of "vulnerabilities" that > we have seen regarding specially crafted replication events, you should not > include in your 10.6 maintenance branch. > > You can also check the branch > knielsen_log_event_read_validation and the mailing list thread: > > > https://lists.mariadb.org/hyperkitty/list/[email protected]/thread/JXEAZRR2LVVZHWPXYJUW7KGYNCAWU2T7/ > > This is a large patch, and fixing these in 10.6 is probably more risk than > benefit. Is that thread about MDEV-40760 ? And that is the one you recommend not backporting at the moment? > But it is also possible that you basically have to fix anything > that's gotten the "CVE" mark due to the politics around "security" these > days, and if so that's a reasonable pragmatic solution also. Various clients' auditors get unhappy if there are known unfixed CVEs. And upgrading to newer versions (including sometimes even minor versions, for reasons that are out of scope for this thread) is less preferable to CVE fix backports and custom package builds based on that. > > I'm working on backporting that 12-patch set to my private 10.6.x > > post-EOL maintenance branch, but I'd be happy to sync up with someone > > closer to the validation process off-list to verify (or disprove) my > > suspicions.. > > I think maintaining a 10.6 maintenance branch is a very valuable > contribution. You write it is your "private branch", but I would hope you > would be making it available to others? Absolutely - once it's ready. It is also a somewhat broader project than just post-EOL 10.6.x, but the scope is limited to CVE fixes only (plus unavoidable dependencies). > I would be happy to help you with > any technical issues (like resolving merge conflicts etc.). Thanks, I appreciate it. I am usually OK with figuring those out, but I will keep your offer in mind. I'll share what I have when it's ready. > We also need to > make sure that you are included in any communication around vulnerability > fixing that happens before the normal MariaDB releases outside of the public > channels, so that release of those fixes can be coordinated and you not > having to scramble only after a normal release is dumped on you. That would be nice, especially if it provides additional information to what is in JIRA. That would evade problems that are the root cause behind my starting this thread (CVEs that don't seem to be mappable to commits or jira tickets). -- Gordan Bobic Database Specialist, Shattered Silicon Ltd. https://shatteredsilicon.net _______________________________________________ discuss mailing list -- [email protected] To unsubscribe send an email to [email protected]
