ffmpeg 6.1.3 please?

[Artem S. Tashkinov]

There are now multiple vulnerabilities in ffmpeg 6.1.2, ​https://www.cybersecurity-help.cz/vdb/SB2024122032 , could you please release 6.1.3?

CVE-2024-36618
CVE-2024-36617
CVE-2024-36616
CVE-2024-35365

ffmpeg 7.x has quite a large number of API breaking changes, so some people are forced to stuck with 6.1.

Thank you!

[MasterQuestionable]

͏    Quite wondering that, why would some mere arithmetic overflow of limited influence:
͏    Be exaggerated as that "high risk security vulnerability" that may enable arbitrary remote code execution..?
͏    ​https://github.com/FFmpeg/FFmpeg/blob/86f73277bf014e2ce36dd2594f1e0fb8b3bd6661/libavformat/westwood_vqa.c#L265
͏    ​https://github.com/FFmpeg/FFmpeg/blob/65ddc74988245a01421a63c5cffa4d900c47117c/libavcodec/packet.h#L536-L540
͏    .
͏    Arithmetic overflow itself won't cause any real issue.
͏    That causes issues is the misuse of overflowed values.

͏    Also:
͏    ​https://github.com/FFmpeg/FFmpeg/commit/7a089ed8e049e3bfcb22de1250b86f2106060857 [1]
͏    The premise (of "ULONG_MAX") holds only in atypical compiling environment.
͏    Also tagged alike?
͏    [ Refer also: ​https://github.com/MasterInQuestion/talk/discussions/15#C-absurdity ]

͏    Is it "医之好治不病以为功"..?
+    "Doctors favored curing non-ill as accomplishment"?

[ [1]
͏    The type casting here would be actually no-op.
͏    For the previous definition:
​https://github.com/FFmpeg/FFmpeg/blob/7a089ed8e049e3bfcb22de1250b86f2106060857/libavformat/avidec.c#L1694
͏    int64_t min_pos, pos;
͏    .
͏    "pos" cannot hold anything larger than "int64_t" permits.
͏    Demonstrable alike:
[[

#include <stdio.h>
#include <stdint.h>

    int main () {
    int32_t x = 2147483647;
    int32_t _ = x + (int64_t) 1;
    printf( "%d", _ );
    };

]]
͏    Unsure what it really addresses:
͏    ​https://github.com/FFmpeg/FFmpeg/commit/108957c661f9e2dc35dea8d55e5e5b1776f4a303 ]