{"id":"393ad0ba-0649-4e18-9801-93990fbd4b92","arxiv_id":"2411.10883","paper_version":2,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"A previously unknown timing side channel in the syncfs system call lets an unprivileged process infer other processes' disk-write activity, enabling covert channels and website/video/app fingerprinting on Linux, Android, and Windows/WSL systems.","lead":"This paper shows that a common system call for saving file changes to disk, called syncfs, can be used by a malicious app to watch what other apps are writing to the disk. The attacker measures how long syncfs takes, and the delay reveals the victim's file-writing activity, enabling website, video, and app fingerprinting as well as hidden communication between two programs.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The demonstrated side channels hinge on an extreme syncfs call rate (120–150 kHz) that the paper's own appendix concedes is anomalous, and Figure 10 shows F1 collapses to ~33% at 15 kHz, so rate-limiting or simple detection would neutralize the practical attacks as presented.","rationale":"I read the central claim as: an unprivileged attacker who repeatedly calls syncfs can infer victim I/O activity because syncfs flushes the shared page cache. The controlled experiments in Sections 3–6 provide reasonable evidence for the underlying mechanism: different I/O operations create measurable syncfs delay differences, and the demonstrated covert and side channels achieve high accuracy in quiet environments. The weakest point in the argument is not the mechanism itself but the operational premise that the attacker can sustain roughly 120–150 kHz syncfs calls without detection or throttling. This premise is load-bearing because Figure 10 shows a 10x reduction in call rate destroys the Android attack's accuracy, and the paper's appended meta-review explicitly identifies the same concern. The authors' response (Appendix B) acknowledges that anomaly detection might be configured to flag high syncfs rates but does not evaluate that countermeasure. Therefore the practical impact of the attacks, as opposed to the existence of the leakage vector, remains conditional on an unrealistic absence of rate limiting or monitoring. I do not see an internal inconsistency in the core mechanism, and I do not agree with any stronger rejection: the leakage is real, the experiments are consistent with the model, and the SNR/noise experiments suggest the signal survives at least moderate background I/O. The reader's CONDITIONAL verdict already captures this balance, so I recommend no change. The one concrete test that would settle the matter is a rate-cap experiment, which would directly determine whether the attack can survive a simple, plausible defense.","tokens_in":22176,"tokens_out":8466,"duration_ms":98457,"concrete_test":"Implement a kernel-level or seccomp-based rate limiter that caps syncfs invocations at 15 kHz and 1 kHz on the same Android and Linux testbeds, then rerun the website, video, and application fingerprinting attacks and the covert channel. If F1 drops to near random and covert bandwidth falls by more than an order of magnitude as Figure 10 suggests, the practical attacks are contingent on an extreme, detectable call rate. As a complement, run a simple userspace daemon that counts syncfs calls per second during normal workloads (browsers, databases, file sync tools) and measure the false-positive rate of flagging rates above 5 kHz, to test whether a detection threshold can separate the attack from benign use.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central mechanism—that syncfs flushes shared dirty buffers and its delay reflects victim I/O—is plausible and supported by the controlled experiments. However, the practical claim that an unprivileged attacker can infer websites, videos, or apps with >90% F1 depends on the attacker invoking syncfs continuously at roughly 150,000 calls/sec on Android (Section 5.3) and 120 kHz on Linux, without being throttled, detected, or denied service. This is the load-bearing premise for all three end-to-end side channels and for the covert-channel bit rate. The paper's own Appendix A.4 flags high sampling rate as a noteworthy concern, and Appendix B concedes that anomaly detection might flag high syncfs() rates without evaluating whether a practical detection threshold exists. Figure 10 quantifies the sensitivity: reducing the Android sampling rate from 150,000 Hz to 15,000 Hz drops application-fingerprinting F1 from 93.49% to 32.99%, and at 15 Hz F1 falls to 8.1%, near random. Thus, the demonstrated attack accuracy is not robust to even a 10x reduction in call rate. If an OS or security monitor rate-limits syncfs to a few thousand calls per second—a plausible, low-cost defense—the side channels degrade to near-random while the covert channel's bandwidth likely collapses. The mechanism may still leak at lower rates, but the paper's headline attack results are contingent on an anomalous and currently unmitigated call pattern. Secondary reproducibility concerns (no code or data artifacts, no confidence intervals for covert-channel bandwidth) reinforce the need for caution but are not the core technical risk.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper identifies the syncfs system call as a timing side-channel vector: because syncfs flushes all dirty buffers of a file system, an unprivileged process can measure syncfs delay to infer the I/O activity of other processes sharing the same file system. The authors demonstrate the underlying leakage with controlled experiments on ext4 and other file systems, build a covert channel over syncfs delay on ext4, ext2, XFS, and NTFS (up to 7.61 Kbps with 1.9% error on NTFS), and present three end-to-end fingerprinting attacks: website fingerprinting and video fingerprinting on Linux, and application fingerprinting on Android, all reporting F1 scores above 90%. They additionally report a cross-container container-detection technique and a cross-container covert channel. The attacks assume a victim and attacker share one mounted file system and that the attacker can invoke syncfs in a tight loop using a high-resolution timer.","tokens_in":22497,"tokens_out":4625,"duration_ms":52013,"significance":"If the results hold, the paper introduces a genuinely new class of OS-level side channels that is distinct from the fsync-contention channels in prior work: the victim only needs to write data, not to call fsync, and the leakage is visible across process and container boundaries. The controlled experiments in Section 3 are carefully designed, and the classifier evaluations use 10-fold cross-validation, which is appropriate for the empirical claims. The cross-file-system covert channel and the container extension broaden the attack surface beyond a single configuration. The main limitation is that the practical claims are contingent on an extremely high syncfs invocation rate, which the paper's own Appendix A.4 flags as anomalous, and on the absence of rate limiting or anomaly detection. Because the central mechanism is plausible and well supported but the operational claims need additional work, the appropriate outcome is major revision.","major_comments":[{"comment":"The end-to-end side-channel attacks rely on the attacker invoking syncfs at approximately 150,000 Hz on Android (Section 5.3) and 120 kHz on Linux, without being throttled or detected. Figure 10 shows that reducing the Android sampling rate from 150,000 Hz to 15,000 Hz drops application-fingerprinting F1 from 93.49% to 32.99%, and at 15 Hz the F1 is 8.1%, close to random guessing. This is a load-bearing premise: it means the headline >90% F1 results do not hold even under a 10x reduction in call rate. Appendix A.4 explicitly concedes that the 150K calls/sec rate is anomalous and likely detectable, and Appendix B responds only that it is unclear whether a low detection threshold is feasible. The paper should either demonstrate a robust attack at rates that are not trivially distinguishable from normal syncfs usage, or provide and evaluate an explicit rate-adaptation or evasion strategy, or substantially temper the practical-validity claims.","section":"§5.3, §7, Fig. 10, Apps. A.4 and B"},{"comment":"The covert-channel results are reported as single-point estimates of bandwidth and error rate, with no confidence intervals, no number of transmissions, and no variance across runs or reboots. Given the large variance in syncfs latency visible in Tables 1 and 8, and the sensitivity of the bit decision to threshold T and the sender loop counts R and K, the claimed maximum bandwidths (up to 7.61 Kbps) and error rates (down to 0.01%) are not yet shown to be stable. The same applies to the cross-container covert channel in Section 6.3. Please report distributions over repeated transmissions and, if possible, across multiple machines or reboots.","section":"Table 2, §6.3, Algorithms 1-2"},{"comment":"The classifier evaluations use 10-fold cross-validation on traces collected in a single experimental session (e.g., 100 traces per website, 100 per video, and one trace per Android app launch). Random cross-validation folds can inflate accuracy when consecutive traces share network conditions, browser cache state, or background I/O state. To support the generalization claims, the paper should include a temporal split or a repeated-session evaluation in which training and test traces come from different collection periods.","section":"§5.1, §5.2, §5.3"}],"minor_comments":[{"comment":"The sampling rate is described as \"around 150,000 cycles/sec\" in Section 5.3 but as \"150,000 Hz\" and \"150 kHz\" in Section 7; please clarify that the quantity is syncfs calls per second, not timer cycles.","section":"§5.3, §7"},{"comment":"Figure 9 has no labeled axes or time scale; please add units so the container mount/unmount spikes can be interpreted quantitatively.","section":"§6, Fig. 9"},{"comment":"The sentence \"File system-specific operations depend on the implementation of each file system\" is repeated verbatim; please remove the duplicate.","section":"§2.2"},{"comment":"The SNR equation is stated as Var(Signal)/Var(Noise), but the text does not define how Signal and Noise are computed from the syncfs latency traces; please specify the estimation procedure.","section":"§3.3"},{"comment":"The receiver pseudocode does not specify how the ending code is detected or how threshold T is chosen; please make the decoding procedure explicit.","section":"Algorithm 1"},{"comment":"No code or data artifact is referenced; making the collection scripts and de-identified traces available would substantially improve reproducibility.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The paper makes a real contribution: the syncfs leakage mechanism is plausible, carefully isolated in Section 3, and distinct from prior fsync-based contention channels. The main risk is overclaiming practical impact given the demonstrated fragility to rate limiting in Figure 10. I would ask the authors to either add a realistic lower-rate evaluation with adapted features or visibly narrow the claims. The lack of an artifact is a secondary but non-trivial reproducibility concern for an empirical security paper."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe syncfs side channel is real, and this paper is the first to show it. Prior fsync-based channels required the victim to call fsync and exploited contention; syncfs flushes all dirty pages on the filesystem, including the victim's, so the victim just has to write. That is a genuinely new vector, and the paper demonstrates it carefully across ext4, ext2, xfs, and NTFS, including a clean write-size calibration and a cross-container extension. I buy the mechanism.\n\nWhat's less convincing is the practical impact. The end-to-end fingerprinting attacks and the upper-range covert-channel bandwidth all depend on the attacker calling syncfs at 120–150 kHz. The paper's own Figure 10 shows Android app fingerprinting F1 drops from 93.49% to 32.99% when the sampling rate is cut to 15 kHz, and to 8.1% at 15 Hz—near random. A simple rate limit of a few thousand calls per second would neutralize these attacks. The paper acknowledges this in Appendix A.4 but does not evaluate detectability or feasible thresholds; Appendix B's response is essentially \"we don't know.\" That is a real gap for the practical claims, not a nitpick.\n\nThere are also standard reproducibility concerns: no code or data, and covert-channel bandwidth/error rates are point estimates without confidence intervals. These are secondary, but they matter given how much weight the paper puts on specific numbers like 7.61 Kbps.\n\nWhat's genuinely good: the controlled experiments that attribute syncfs delay to specific I/O buffers (page cache vs journal vs inode) are solid. The observation that write size below 4KB scales linearly while above 4KB saturates due to flusher threads is a useful datapoint. The cross-container demonstration, including mount/unmount spikes from lock contention, is a nice addition.\n\nNet: the underlying vulnerability is worth taking seriously. The attack as demonstrated works in a quiet lab environment, but the practical side channels are brittle to a plausible, cheap defense. I'd send this to peer review—it's a solid empirical contribution with a new vector—but I'd push the authors to either show the attacks survive at sustainable sampling rates or clearly scope the threat to environments where such rates are tolerated.","headline":"Real syncfs leak, well-measured, but the end-to-end attacks hinge on a 120–150 kHz call rate that the paper itself flags as anomalous.","tokens_in":23035,"tokens_out":4318,"would_cite":true,"duration_ms":39685,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"syncfs delay lets any app spy on others' I/O activity","keywords":["syncfs","side channel","covert channel","file system security","page cache timing","cross-container attack","website fingerprinting","Android application fingerprinting"],"falsifier":"Measure syncfs latency while a victim writes to a file on the same mount, then repeat with the victim writing via O_DIRECT (bypassing the page cache) or to a separate mount; if syncfs delay no longer tracks the victim's writes, the leakage depends on shared-buffer behavior rather than on the flush-all semantics of the call itself.","tokens_in":21978,"feed_emoji":"🔓","tokens_out":4819,"duration_ms":46432,"temperature":0.7,"pith_summary":"This paper claims that the Linux syncfs system call, when invoked by an unprivileged process, flushes not only that process's own dirty data but the file system's entire shared page cache, journal, and inode state. Because the flush work scales with what every other process on the same mount has written, the call's duration becomes a readable timing signal about other domains' I/O. The authors use this signal to build a covert channel reaching 7.61 Kbps on NTFS and three fingerprinting attacks (websites, videos, Android apps) with F1 scores above 90%. The significance is that logical isolation between processes, containers, and across OS boundaries is broken by a standard, unprivileged system call that requires no root permissions.","feed_headline":"syncfs delay lets any app spy on others' I/O activity","feed_subtitle":"Unprivileged process measures flush time to fingerprint sites, videos, and app launches with >90% F1 accuracy.","key_machinery":"The central mechanism is the syncfs system call itself, which synchronizes a whole superblock: it marks dirty inodes, issues write-back for all dirty pages through sync_blockdev_nowait() and sync_blockdev(), and finally issues a device-level flush. Because the page cache, inode cache, and journal are shared across processes and containers, the delay of this single call encodes the write behavior of every other isolation domain sharing the mount. The paper's measurement primitive is the unprivileged high-resolution timer (rdtsc on x86, CNTVCT_EL0 on ARM) wrapped around repeated syncfs calls.","core_discovery":"On the paper's own terms, the central discovery is that syncfs acts as a system-wide flush barrier whose latency is proportional to the volume and kind of dirty state accumulated from all clients of the same file system. Four measured I/O operations (write, write with O_SYNC, ftruncate, rename) each inflate syncfs delay by at least 16 times over baseline, and delay grows linearly with write sizes below the 4 KB page threshold before flattening due to kernel flusher-thread parallelism. Because the victim need not call any synchronization primitive, merely write data, this leakage is richer than the contention-based fsync channels proposed earlier. The paper demonstrates the channel across ext4, ext2, XFS, and NTFS (via WSL), across Docker containers, and on Android, supporting the claim that the flush-all behavior is a general property of shared file system implementations.","pith_inferences":["The flush-all design is a property of shared file system state, so analogous sync primitives on other operating systems (for example, macOS or BSD) may exhibit the same timing leakage even though the paper tests only Linux and NTFS via WSL.","An OS redesign that limits syncfs to flushing only the caller's own dirty pages would eliminate the leakage; the paper instead proposes tagging temporary files so their dirty pages are exempt from syncfs flushes.","The attack's extreme sampling rate (about 150,000 calls per second on Android) is an observable behavioral signature, suggesting anomaly-based detection that caps syncfs frequency could trade acceptable false positives for a hard ceiling on attack accuracy.","The linear write-size inference below 4 KB opens the possibility of finer-grained leakage, such as keystroke timing or fragment-length inference, when a victim writes small chunks at regular intervals."],"forward_implications":["An unprivileged attacker on a default Linux or Android install can fingerprint which website, video, or app a victim uses by watching syncfs delay patterns, without any file access or special permissions.","The covert channel works across OS isolation boundaries, including Linux on WSL flushing NTFS and across Docker containers that share a disk.","Because the victim only performs ordinary writes, defenses that monitor application flush behavior or fsync calls do not detect this leakage.","Rate-limiting syncfs degrades rather than eliminates the attack: the paper's own data show Android fingerprinting F1 falling from 93.49% at 150 kHz sampling to 32.99% at 15 kHz and to 8.1% at 15 Hz, near random guessing.","Container isolation does not contain the leak, enabling container start/stop detection and a cross-container covert channel with 0.23 Kbps bandwidth at 2.4% error rate."],"supporting_citations":[{"why":"Chen et al., Write+Sync, is the prior file-system synchronization covert channel that this work contrasts with, since syncfs leakage does not require the victim to call any flush operation.","marker":"[17]"},{"why":"Jiang et al., Sync+Sync, is the fsync-contention covert channel and website fingerprinting baseline whose low accuracy (two reliably identified websites) the syncfs attack is measured against.","marker":"[18]"},{"why":"Rauscher et al., Idleleak, supplies the TSC-based synchronization scheme used to align sender and receiver in the covert channel design.","marker":"[1]"},{"why":"Gruss et al., Page cache attacks, provides the prior demonstration that the shared OS page cache leaks access patterns, which this work extends to write timing through syncfs.","marker":"[76]"},{"why":"Zhang et al. provides the SNR greater than 1 exploitability criterion used to justify that the syncfs signal remains usable under background noise.","marker":"[16]"}],"fun_headline_variants":["syncfs: the flush that leaks your I/O secrets","File system sync exposes cross-app activity","Timing syncfs reveals what other processes write","Syncfs delay: a new side channel for spying","How syncfs turns flush into a spying tool"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The attack requires the attacker to invoke syncfs in a tight loop at very high frequency (about 150,000 times per second on Android and 120 kHz on Linux) without being detected, rate-limited, or throttled, and the victim's writes must go through the shared page cache of a single mounted file system.","fun_headline_variants_meta":{"raw":{"variants":["syncfs: the flush that leaks your I/O secrets","File system sync exposes cross-app activity","Timing syncfs reveals what other processes write","Syncfs delay: a new side channel for spying","How syncfs turns flush into a spying tool"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000361,"raw_usage":{"total_tokens":1996,"prompt_tokens":1039,"completion_tokens":957,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":655,"completion_tokens_details":{"reasoning_tokens":897}},"tokens_in":655,"tokens_out":957,"duration_ms":8124,"temperature":1.0,"reasoning_tokens":897,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T19:11:43.401350+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Measure syncfs latency while a victim writes to a file on the same mount, then repeat with the victim writing via O_DIRECT (bypassing the page cache) or to a separate mount; if syncfs delay no longer tracks the victim's writes, the leakage depends on shared-buffer behavior rather than on the flush-all semantics of the call itself.","supporting_citations":[{"cited_title":"Sync+Sync: A covert channel built on fsync with storage,","cited_arxiv_id":null,"evidence_quote":"Jiang et al., Sync+Sync, is the fsync-contention covert channel and website fingerprinting baseline whose low accuracy (two reliably identified websites) the syncfs attack is measured against."},{"cited_title":"Page cache attacks,","cited_arxiv_id":null,"evidence_quote":"Gruss et al., Page cache attacks, provides the prior demonstration that the shared OS page cache leaks access patterns, which this work extends to write timing through syncfs."},{"cited_title":"It’s all in your head (set): Side-channel attacks on AR/VR systems,","cited_arxiv_id":null,"evidence_quote":"Zhang et al. provides the SNR greater than 1 exploitability criterion used to justify that the syncfs signal remains usable under background noise."}],"review_version":1}