Smart contracts have become a foundational component of blockchain systems, enabling decentralized, transparent, and autonomous execution of application logic across various domains, including decentralized finance (DeFi), gaming, and digital identity. Due to their immutable and trustless nature, smart contracts often manage and transfer substantial amounts of assets without human intervention. However, vulnerabilities in smart contracts can lead to substantial financial losses. Among these, access control vulnerabilities are particularly critical, typically originating from inadequately designed or incorrectly implemented permission mechanisms. Most existing methods for detecting access control vulnerabilities are based on static analysis, which heavily relies on manually defined rules and pattern matching. While these methods are efficient at identifying certain classes of known vulnerabilities, they are inherently limited in scope and generalization. In particular, they often fail to capture the underlying business logic of smart contracts.In this paper, we propose an LLM-based multi-agent system, named ACTaint, for detecting access control vulnerabilities in Solidity smart contracts. ACTaint first performs static analysis to guide the sink agent in identifying potential sinks. Then, based on the identified sinks, the taint agent conducts taint analysis to determine whether a data flow exists from untrusted sources to these sinks. We evaluate our approach on three datasets: known CVE cases, a set of 624 real-world smart contracts, and another set of 93 real-world smart contracts. The results demonstrate that our method outperforms existing tools in both datasets. On the first dataset, our approach outperforms state-of-the-art tools, including AChecker and GPTLens, achieving higher recall and F1-score. On the second dataset, our method surpasses the leading static analysis tool AChecker, with a 8.3% improvement in precision and an 9.7% improvement in F1-score.

Concurrent programs must be thoroughly tested, as concurrency bugs are notoriously hard to detect. Code coverage criteria can be used to quantify the richness of a test suite (e.g., whether a program has been tested sufficiently) or provide practical guidelines on test case generation (e.g., as objective functions used in program fuzzing engines). Traditional code coverage criteria are, however, designed for sequential programs and thus ineffective for concurrent programs. In this work, we introduce a novel code coverage criterion for testing thread-safe classes called MAP-coverage (short for memory-access patterns). The motivation is that concurrency bugs are often correlated with certain memory-access patterns, and thus it is desirable to comprehensively cover all memory-access patterns. Furthermore, we propose a testing method for maximizing MAP-coverage. Our method has been implemented as a self-contained toolkit, and the experimental results on 20 benchmark programs show that our toolkit outperforms existing testing methods. Lastly, we show empirically that there exists positive correlation between MAP-coverage and the effectiveness of a set of test executions.

Concurrency bugs of a multi-threaded program may only manifest with certain scheduling, i.e., they are heisenbugs which are observed only from time to time if we execute the same program with the same input multiple times. They are notoriously hard to fix. In this work, we propose an approach to automatically fix concurrency bugs. Compared to previous approaches, our key idea is to systematically fix concurrency bugs by inferring locking policies from failure inducing memory-access patterns. That is, we automatically identify memory-access patterns which are correlated with the manifestation of the bug, and then conjecture what is the intended locking policy of the program. Afterwards, we fix the program by implementing the locking policy so that the failure inducing memory-access patterns are made impossible. We have implemented our approach in a toolkit called PFix which supports Java programs. We applied PFix to a set of 23 concurrency bugs and are able to automatically fix 19 of them. In comparison, Grail which is the state-of-the-art tool for fixing concurrency bugs in Java programs can only fix 3 of them correctly.