michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 8.0 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
kasper93 has quit [Remote host closed the connection]
kasper93 has joined #ffmpeg-devel
_av500_ has quit [Remote host closed the connection]
_av500_ has joined #ffmpeg-devel
<BtbN>
jkqxz: well, in this case the platform is always going to be Windows 10 or higher. The code just gets a lot uglier without variable size arrays, and it rapid-fires those allocations, so it'd potentially be hundreds of av_malloc and free in a row
<BtbN>
And it's supposed to contain Window Titles, so the size is rather constrained. But if I get it too small, the whole thing aborts with an error
<BtbN>
And allocating a buffer in the filter struct for it and dynamically growing it seems a bit overkill
<BtbN>
There doesn't seem to be a difference for VLAs between the two at least
<BtbN>
But if they're optional, they can't really be used...
<ramiro>
BtbN: this is only init code, right? the performance hit should be minimal to use malloc here.
<BtbN>
Spamming a ton of malloc/free can horribly fragment the memory though, and is generally ugly
<BtbN>
wonder if I should just put a 4kB buffer on the stack or something and hope nobody ever makes longer window titltes than that
<BtbN>
And it will need to re-run if the window gets lost at runtime, so not purely init
<ramiro>
BtbN: IMO allocating a buffer in the filter struct and dynamically growing it if needed would be better than using the stack and hoping for small titles.
<BtbN>
Well, that would then potentially waste a ton of memory if some random window has a humongous title
<BtbN>
Windows apparently has no size limit for the Window title. It can be as long as the null terminated string can carry it
<ramiro>
BtbN: only while you're enumerating. free it afterwards.
<BtbN>
I think a fixed size buffer might be the saner approach
<BtbN>
I can already see the fuzzer report about memory growth due to silly long window title
<BtbN>
If someone has a really long title, it'll just fail
HarshK23 has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
<jkqxz>
BtbN: That code appears to allow an attacker who can control window titles (e.g. a web page) to be able to make arbitrary writes to the memory of your process without it noticing, so please don't do that.
<BtbN>
I don't see how it would achieve that
<jkqxz>
Attacker sets their window title to a string of length SP - target address, your code reads the length and puts a huge VLA on the stack, SP is now around the target address, attacker now sets their window title to the data they want to write with a short length, your code reads the window title into the target address.
<jkqxz>
Nothing notices because it never writes the intermediate addresses, so the stack overflow isn't visible.
<BtbN>
If that's possible, why are VLAs a feature? I'd expect the compiler to make that impossible.
<jkqxz>
(It might be caught by some other stack protection things.)
<BtbN>
sure, it can stack overflow. But I'd expect a crash then, and nothing else
<jkqxz>
Because you don't allocate VLAs with arbitrary size.
indecisiveturtle has quit [Quit: indecisiveturtle]
<BtbN>
there's for some reason hundreds or thousands of "Windows"
<BtbN>
so I really don't want to malloc/free spam in there
<jkqxz>
The stack overwrite will only be caught normally if it hits the guard page, but the attack I described above doesn't if the attacker wins the race to only write a smaller amount.
<jkqxz>
Lynne: Did the Vulkan decode work before that change? And does it still work after?
<Lynne>
jkqxz: it does work, it just fixes those samples according to nowrep
<jkqxz>
Can you run all the VP9 tests with HWACCEL= and see if there is anything else lurking in there?
<Lynne>
not on this machine currently, do can you run it?
elvis_a_presley has quit [Quit: smoke-bomb ; grapple-hook]
elvis_a_presley has joined #ffmpeg-devel
sb has joined #ffmpeg-devel
sb has quit [Client Quit]
sb1066 has joined #ffmpeg-devel
<sb1066>
Hey, since ffmpeg-7.1, ffplay depends on libavutil, but it seems the configure script does not include this dependency, which leads to errors when using static linking, see the ffplay_deps variable in the configure script
microchip_ has quit [Quit: Do coders dream of sheep() ?]
<BtbN>
sb1066: every library already depends on libavutil, so that should be a non-issue?
putacho is now known as microchip_
<sb1066>
With 7.0, this was not the case, but perhaps its an issue with link order
<sb1066>
When using static linking, every lib has to be explicitly linked, e.g., when ffplay depends on avcodec, and avcodec depends on avutil, avutil needs to be explicitly linked with ffplay
<BtbN>
every library is already using libavutil, so if that wasn't taken care of, it'd have virtually always been failing already
<BtbN>
linking static ffplay works just fine for me on any version
<BtbN>
no idea, links fine for me with both clang and gcc
<BtbN>
master is build-tested quite extensively, so a link failure would have long been noticed
indecisiveturtle has joined #ffmpeg-devel
<BtbN>
"/usr/x86_64-w64-mingw32/usr/include/stdio.h:365: note: ‘-Wmisleading-indentation’ is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers" wow, never seen that one before. Those Windows-Headers must be huge
<sb1066>
Yea could be my setup, I cross compile for homebrew on the ps5
<sb1066>
It works with 7.0.1, but I will investigate
rvalue has quit [Read error: Connection reset by peer]