Chunked uploads can silently corrupt slide files (no offset validation / out-of-order chunk handling)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 45/100
Direzione di ricerca
Inizia tracciando il punto di ingresso per il caricamento dei chunk di SlideServer e il comportamento di /finish descritto nell’issue. Riproduci i casi di caricamenti fuori ordine e di caricamenti concorrenti usando gli scenari Python o browser forniti, quindi esamina come vengono gestiti gli offset e i file temporanei. Il lavoro è completato quando gli offset non validi non producono un file corrotto considerato riuscito e il comportamento di ripresa e i controlli di integrità corrispondono all’ambito concordato.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
During testing, I discovered that SlideLoader’s chunked upload pipeline can silently produce corrupted slide files when chunks arrive out of order or when the browser sends multiple parallel chunk uploads.
This happens because SlideServer writes chunks purely based on the client-provided offset without validating:
-
whether the chunk order is correct
-
whether the offset matches the current temp file size
-
whether chunks overlap
-
whether the client retried a previous offset
-
whether the full file content matches the original
This results in corrupted slides being saved without any error.
What works
✔ Sequential Python upload
Uploading a large slide (>2GB) using a simple Python script sending sequential chunks works correctly.
✔ Sequential browser upload
A browser-based uploader (using Fetch API) also works when chunks are strictly uploaded one-by-one.
What breaks
❌ Out-of-order chunks
If chunks are intentionally sent in the wrong order (e.g., 0 → 2 → 1 → 3), SlideServer still accepts them and produces a corrupted file.
Example mismatch:
Original SHA256: 01B1513BFB09718D270EC02B75985B0EE32091BA2CB50D286E760BAB9534DDF1
Uploaded SHA256: 2B8E2616B4668452A2A6C6373BC9E490DDA6D4C8F2F1DED9164E6864E7957824
❌ Parallel browser upload
Using a browser uploader that issues chunk uploads concurrently (similar to how Chrome behaves during heavy uploads or retry conditions), uploads also become corrupted.
The server still returns 200 and proceeds to finish, even though the resulting file does not match the original.
To Reproduce
1. Python Out-of-Order Script
Upload a slide using a Python script that intentionally sends chunks in the wrong order.
Chunk order example:
chunk 0 (offset 0)
chunk 2 (offset 1*chunk_size)
chunk 1 (offset 2*chunk_size)
then chunks 3+
SlideServer will:
- accept all chunks
- return 200
- save a corrupted file
2. Browser Aggressive Upload
Create a small browser uploader using Fetch that uploads chunks concurrently (like Chrome does).
With concurrency = 6, I observed:
- out-of-order requests
- overlapping offsets
- retries
- corrupted final file
### Expected Behavior
SlideServer should:
- Reject out-of-order chunks (409 Offset Mismatch)
- Validate offset == current_temp_file_size
- Prevent overlapping writes
- Optionally verify SHA256 at /finish
- Expose correct resume behavior if validation fails
### Actual Behavior
- Out-of-order chunks are written without checking
- Final file is corrupted but server returns success
- No warnings or log messages
- No way for client to detect corruption
Browser concurrency triggers silent corruption
Screenshots
Desktop:
- OS: Windows 11 (64-bit)
- Browser: Google Chrome
- Browser Version: 119.0.6045.200
- Python: Anaconda Python 3.10 (used for running SlideServer and tests)
- SlideLoader setup: Local clone on Windows filesystem (D:\Gsoc\SlideLoader)
Suggested Fix
I can provide a PR including:
- offset validation:
current_size = os.path.getsize(tmppath)
if offset != current_size:
return 409
- per-token write locks
- optional SHA256 integrity check
- improved error responses
Let me know if you’d like a PR
- Lingua principale
- Python
- Stelle
- 3
- Fork
- 23
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di camicroscope/SlideLoader
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
camicroscope/SlideLoader#49 · 4 commenti ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
camicroscope/SlideLoader#42 · 1 commento ·
Tutte le issue di camicroscope/SlideLoader
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
huggingface/peft#3955 ·
I maintainer di solito rispondono entro 1 giorno
-
author-page correction
Difficoltà 2/5 1-3 ore Idoneità per principianti 60/100
acl-org/acl-anthology#10313 ·
I maintainer di solito rispondono entro 1 giorno
-
anime duplicate exception request-theme
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
LizardByte/ThemerrDB#8926 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
huggingface/transformers#49556 ·
I maintainer di solito rispondono entro 1 giorno
-
area/security bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
mozilla-ai/otari#2245 ·
I maintainer di solito rispondono entro 1 giorno