diff --git a/rules/S2445/comments-and-links.adoc b/rules/S2445/comments-and-links.adoc index 8716733989d..940d77d87fa 100644 --- a/rules/S2445/comments-and-links.adoc +++ b/rules/S2445/comments-and-links.adoc @@ -1,5 +1,7 @@ === is related to: S1860 +=== is related to: S6507 + === on 5 Feb 2016, 17:54:44 Ann Campbell wrote: Scope expanded & may now apply to C# [~tamas.vajk] diff --git a/rules/S2445/csharp/message.adoc b/rules/S2445/csharp/message.adoc index d1bbd4f3cfe..57bb9a21891 100644 --- a/rules/S2445/csharp/message.adoc +++ b/rules/S2445/csharp/message.adoc @@ -2,8 +2,6 @@ Do not lock on writable field "xxx", use a readonly field instead. -Do not lock on local variable "xxx", use a readonly field instead. - Do not lock on a new instance because is a no-op, use a readonly field instead. Do not lock on strings as they can be interned, use a readonly field instead. diff --git a/rules/S2445/csharp/rule.adoc b/rules/S2445/csharp/rule.adoc index f67ba05c23a..3bc3c328306 100644 --- a/rules/S2445/csharp/rule.adoc +++ b/rules/S2445/csharp/rule.adoc @@ -2,7 +2,7 @@ Locking on a class field synchronizes not on the field itself, but on the object 1. Locking on a non-`readonly` field makes it possible for the field's value to change while a thread is in the code block locked on the old value. This allows another thread to lock on the new value and access the same block concurrently. -2. Locking on a local variable or a new instance of an object can undermine synchronization because two different threads running the same method in parallel will potentially lock on different instances of the same object, allowing them to access the synchronized block at the same time. +2. Locking on a new instance of an object undermines synchronization because two different threads running the same method in parallel will lock on different instances of the same object, allowing them to access the synchronized block at the same time. 3. Locking on a string literal is also dangerous since, depending on whether the string is interned or not, different threads may or may not synchronize on the same object instance. diff --git a/rules/S6507/comments-and-links.adoc b/rules/S6507/comments-and-links.adoc new file mode 100644 index 00000000000..1b585077cf7 --- /dev/null +++ b/rules/S6507/comments-and-links.adoc @@ -0,0 +1,8 @@ +=== is related to: S2445 + +=== on 3 Mar 2022, 10:46:00 Antonio Aversa wrote: +Rule derived from the C# version of S2445, due to this branch of the rule generating a lot of FPs. + +Valid scenarios using local variables include retrieval of the object being locked from a collection or complex logic, to support a fine graned synchronization, renaming of a readonly field in the context of the current method or locking inside a loop, on the iteration variable. + +The rule still makes sense, however, for all scenarios which don't require advanced synchronization, and prevents synchronization issues captured by S2445 to be circumvented via a local variable. For example via `var local = new object(); lock (local) { ... }`. diff --git a/rules/S6507/csharp/highlighting.adoc b/rules/S6507/csharp/highlighting.adoc new file mode 100644 index 00000000000..8b4b9efcce8 --- /dev/null +++ b/rules/S6507/csharp/highlighting.adoc @@ -0,0 +1,4 @@ +=== Highlighting + +locked object in `lock (xxx)` statement + diff --git a/rules/S6507/csharp/message.adoc b/rules/S6507/csharp/message.adoc new file mode 100644 index 00000000000..b96de6b2d06 --- /dev/null +++ b/rules/S6507/csharp/message.adoc @@ -0,0 +1,4 @@ +=== Message + +Do not lock on local variable "xxx", use a readonly field instead. + diff --git a/rules/S6507/csharp/metadata.json b/rules/S6507/csharp/metadata.json new file mode 100644 index 00000000000..0db3279e44b --- /dev/null +++ b/rules/S6507/csharp/metadata.json @@ -0,0 +1,3 @@ +{ + +} diff --git a/rules/S6507/csharp/rule.adoc b/rules/S6507/csharp/rule.adoc new file mode 100644 index 00000000000..b8668c67a85 --- /dev/null +++ b/rules/S6507/csharp/rule.adoc @@ -0,0 +1,56 @@ +Locking on a local variable can undermine synchronization because two different threads running the same method in parallel will potentially lock on different instances of the same object, allowing them to access the synchronized block at the same time. + +== Noncompliant Code Example + +[source,csharp] +---- +private void DoSomething() +{ + object local = new object(); + // Code potentially modifying the local variable ... + + lock (local) // Noncompliant + { + // ... + } +} +---- + + +== Compliant Solution + +[source,csharp] +---- +private readonly object lockObj = new object(); + +private void DoSomething() +{ + lock (lockObj) + { + //... + } +} +---- + +== See + +* https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/statements/lock[Lock Statement] - lock statement - ensure exclusive access to a shared resource +* https://cwe.mitre.org/data/definitions/412[MITRE, CWE-412] - Unrestricted Externally Accessible Lock +* https://cwe.mitre.org/data/definitions/413[MITRE, CWE-413] - Improper Resource Locking + +ifdef::env-github,rspecator-view[] + +''' +== Implementation Specification +(visible only on this page) + +include::message.adoc[] + +include::highlighting.adoc[] + +''' +== Comments And Links +(visible only on this page) + +include::../comments-and-links.adoc[] +endif::env-github,rspecator-view[] diff --git a/rules/S6507/metadata.json b/rules/S6507/metadata.json new file mode 100644 index 00000000000..6f658a329d6 --- /dev/null +++ b/rules/S6507/metadata.json @@ -0,0 +1,33 @@ +{ + "title": "Blocks should not be synchronized on local variables", + "type": "BUG", + "status": "ready", + "remediation": { + "func": "Constant\/Issue", + "constantCost": "15min" + }, + "tags": [ + "cwe", + "multi-threading" + ], + "extra": { + "replacementRules": [ + + ], + "legacyKeys": [ + + ] + }, + "defaultSeverity": "Major", + "ruleSpecification": "RSPEC-6507", + "sqKey": "S6507", + "scope": "All", + "securityStandards": { + "CWE": [ + 412, + 413 + ] + }, + "defaultQualityProfiles": [ ], + "quickfix": "unknown" +}