Merge pull request #718 from github/removing-lgtm-references

jkcso · web-flow · commit 9335e3208cf4 · 2022-11-30T22:58:35.000Z
Replaces databases, blog URLs and removes lgtm
diff --git a/CodeQL_Queries/cpp/ChakraCore-bad-overflow-check/README.md b/CodeQL_Queries/cpp/ChakraCore-bad-overflow-check/README.md
@@ -1,3 +1 @@
-Use [this snapshot](https://downloads.lgtm.com/snapshots/cpp/microsoft/chakracore/ChakraCore-revision-2017-April-12--18-13-26.zip)
-
-We now also have this query in our default suite: https://lgtm.com/rules/2156560627/
+Use [this snapshot](https://github.com/github/securitylab/releases/download/chakracore-codeql-database/ChakraCore-revision-2017-April-12--18-13-26.zip)
diff --git a/CodeQL_Queries/cpp/Facebook_Fizz_CVE-2019-3560/README.md b/CodeQL_Queries/cpp/Facebook_Fizz_CVE-2019-3560/README.md
@@ -1,5 +1,5 @@
 # Facebook Fizz integer overflow vulnerability (CVE-2019-3560)
 
-Use [this snapshot](https://downloads.lgtm.com/snapshots/cpp/facebook/fizz/facebookincubator_fizz_cpp-srcVersion_c69ad1baf3f04620393ebadc3eedd130b74f4023-dist_odasa-lgtm-2019-01-13-f9dca2a-universal.zip) for the demo.
+Use [this snapshot](https://github.com/github/securitylab/releases/download/facebook-codeql-database/facebookincubator_fizz_cpp-srcVersion_c69ad1baf3f04620393ebadc3eedd130b74f4023-dist_odasa-lgtm-2019-01-13-f9dca2a-universal.zip) for the demo.
 
 [Fizz](https://github.com/facebookincubator/fizz) contained a remotely triggerable infinite loop. For more details about the bug, see this [blog post](https://securitylab.github.com/research/facebook-fizz-CVE-2019-3560). A proof-of-concept exploit is available [here](https://github.com/github/securitylab/tree/95c0bcc670f3b3d98a4d578f8993f8138092b94f/SecurityExploits/Facebook/Fizz/CVE-2019-3560).
diff --git a/CodeQL_Queries/cpp/Qualcomm-MSM-copy_from_user/README.md b/CodeQL_Queries/cpp/Qualcomm-MSM-copy_from_user/README.md
@@ -1,5 +1,5 @@
-[Blog post](https://lgtm.com/blog/qualcomm_copy_from_user)
+[Blog post](https://securitylab.github.com/research/stack-buffer-overflow-qualcomm-msm/)
 
-[Snapshot for this demo](https://downloads.lgtm.com/snapshots/cpp/qualcomm/msm/msm-4.4-revision-2017-May-07--08-33-56.zip)
+[Snapshot for this demo](https://github.com/github/securitylab/releases/download/qualcomm-msm-codeql-database/msm-4.4-revision-2017-May-07--08-33-56.zip)
 
 The blog post was written before we had the C++ dataflow library, so these demo queries are a bit different than the blog post.
diff --git a/CodeQL_Queries/cpp/XNU_DTrace_CVE-2017-13782/README.md b/CodeQL_Queries/cpp/XNU_DTrace_CVE-2017-13782/README.md
@@ -1,5 +1,5 @@
-[Blog post](https://lgtm.com/blog/apple_xnu_dtrace_CVE-2017-13782)
+[Blog post](https://securitylab.github.com/research/apple-xnu-dtrace-CVE-2017-13782/)
 
 Bug was fixed in [macOS High Sierra 10.13.1](https://support.apple.com/en-us/HT208221).
 
-[This snapshot](https://downloads.lgtm.com/snapshots/cpp/apple/xnu/XNU-revision-2017-June-13--15-52-38.zip) (macOS 10.13) has the bug.
+[This snapshot](https://github.com/github/securitylab/releases/download/xnu-codeql-database/XNU-revision-2017-June-13--15-52-38.zip) (macOS 10.13) has the bug.
diff --git a/CodeQL_Queries/cpp/XNU_NFS_Boot_CVE-2018-4136_CVE-2018-4160/README.md b/CodeQL_Queries/cpp/XNU_NFS_Boot_CVE-2018-4136_CVE-2018-4160/README.md
@@ -1,5 +1,5 @@
-[Blog post](https://lgtm.com/blog/apple_xnu_nfs_boot_CVE-2018-4136_CVE-2018-4160)
+[Blog post](https://securitylab.github.com/research/apple-xnu-nfs-boot/)
 
 Bug was fixed in [macOS High Sierra 10.13.4](https://support.apple.com/en-gb/HT208692).
 
-[This snapshot](https://downloads.lgtm.com/snapshots/cpp/apple/xnu/xnu-4570.41.2_macOS-10.13.3_Semmle-1.16.1.zip) has the bug.
+[This snapshot](https://github.com/github/securitylab/releases/download/xnu-macos10.13.3-codeql-database/xnu-4570.41.2_macOS-10.13.3_Semmle-1.16.1.zip) has the bug.
diff --git a/CodeQL_Queries/cpp/XNU_icmp_error_CVE-2018-4407/00_mbuf_copydata_tainted_size.ql b/CodeQL_Queries/cpp/XNU_icmp_error_CVE-2018-4407/00_mbuf_copydata_tainted_size.ql
@@ -10,7 +10,7 @@
 /*
  * This query is explained in detail in this blog post:
  *
- * https://lgtm.com/blog/apple_xnu_icmp_error_CVE-2018-4407
+ * https://securitylab.github.com/research/apple-xnu-icmp-error-CVE-2018-4407/
  *
  * It is based on the assumption that the function `m_mtod`, which returns
  * a pointer to the data stored in an `mbuf`, often returns a buffer
diff --git a/CodeQL_Queries/cpp/XNU_icmp_error_CVE-2018-4407/README.md b/CodeQL_Queries/cpp/XNU_icmp_error_CVE-2018-4407/README.md
@@ -1,5 +1,5 @@
 # Apple XNU icmp_error CVE-2018-4407
 
-Use [this snapshot](https://downloads.lgtm.com/snapshots/cpp/apple/xnu/xnu-4570.71.2_macOS-10.13.6_Semmle-1.18.0.zip) for the demo.
+Use [this snapshot](https://github.com/github/securitylab/releases/download/xnu-macos10.13.6-codeql-database/xnu-4570.71.2_macOS-10.13.6_Semmle-1.18.0.zip) for the demo.
 
-There are two parts to this demo. The first part is `00_mbuf_copydata_tainted_size.ql`, which is the dataflow query that found the bug. It is explained in detail in [this blog post](https://lgtm.com/blog/apple_xnu_icmp_error_CVE-2018-4407). The problem with this query is that it does not find the true source of the untrusted data. This is because it assumes that any call to the function named `m_mtod` can return untrusted data. But not every `mbuf` contains untrusted data. So the second part of the demo, corresponding to [this blog post](https://lgtm.com/blog/apple_xnu_icmp_nfs_pocs), is to use dataflow analysis to find a path that gets an untrusted `mbuf` into `icmp_error`. The second part of the demo is developed in steps, starting with `01_paths_to_icmp_error.ql`.
+There are two parts to this demo. The first part is `00_mbuf_copydata_tainted_size.ql`, which is the dataflow query that found the bug. It is explained in detail in [this blog post](https://securitylab.github.com/research/apple-xnu-icmp-error-CVE-2018-4407/). The problem with this query is that it does not find the true source of the untrusted data. This is because it assumes that any call to the function named `m_mtod` can return untrusted data. But not every `mbuf` contains untrusted data. So the second part of the demo, corresponding to [this blog post](https://securitylab.github.com/research/apple-xnu-exploit-icmp-poc/), is to use dataflow analysis to find a path that gets an untrusted `mbuf` into `icmp_error`. The second part of the demo is developed in steps, starting with `01_paths_to_icmp_error.ql`.
diff --git a/CodeQL_Queries/cpp/XNU_packet-mangler_CVE-2018-4249/README.md b/CodeQL_Queries/cpp/XNU_packet-mangler_CVE-2018-4249/README.md
@@ -1,4 +1,4 @@
-https://lgtm.com/blog/apple_xnu_packet_mangler_CVE-2017-13904
+https://securitylab.github.com/research/CVE-2018-4249-apple-xnu-packet-mangler/
 
 There were multiple bugs in `packet_mangler.c`. One of the infinite loop bugs was fixed in macOS High Sierra 10.13.2. The other bugs were fixed in macOS High Sierra 10.13.5.
 
@@ -8,6 +8,6 @@ For a demo, the best query to show is `tcphdr_mbuf_copydata.ql`, because it show
 
 `InfiniteLoop.ql` is a query inspired by one of the bugs in this code: the loop might not terminate because the loop counter is updated with a compound assignment (`+=`). We wrote an exploit which causes the right hand side of the assignment to be zero, which means that the loop runs forever.
 
-All three queries find results in [this snapshot](https://downloads.lgtm.com/snapshots/cpp/apple/xnu/XNU-revision-2017-June-13--15-52-38.zip) (macOS 10.13).
+All three queries find results in [this snapshot](https://github.com/github/securitylab/releases/download/xnu-macos10.13-codeql-database/XNU-revision-2017-June-13--15-52-38.zip) (macOS 10.13).
 
-The queries also find results in [this newer snapshot for 10.13.3](https://downloads.lgtm.com/snapshots/cpp/apple/xnu/xnu-4570.41.2_macOS-10.13.3_Semmle-1.16.1.zip). Apple thought they had fixed the infinite loop bug in 10.13.2, by changing the loop condition to a `>`. They were wrong.
+The queries also find results in [this newer snapshot for 10.13.3](https://github.com/github/securitylab/releases/download/xnu-macos10.13.3-codeql-database/xnu-4570.41.2_macOS-10.13.3_Semmle-1.16.1.zip). Apple thought they had fixed the infinite loop bug in 10.13.2, by changing the loop condition to a `>`. They were wrong.
diff --git a/CodeQL_Queries/cpp/libjpeg-turbo-oob/README.md b/CodeQL_Queries/cpp/libjpeg-turbo-oob/README.md
@@ -2,7 +2,7 @@ This is demo is an example of variant analysis on a recent [bugfix](https://gith
 
 The fix prevents an out-of-bounds access when processing malformed BMP files: when reading a BMP file, the library allocates a colour map based on the number of colours declared in the BMP header. Later on, individual bytes are read from the file and used as indices into this colour map. Previously, this was done without checking whether the byte actually represented a valid colour, which could cause an out-of-bounds access. The fix introduces a field in the same struct as the colour map that records its size, and checks the index against it, aborting with an error if the index is out of range.
 
-A snapshot of libjpeg-turbo from before the fix is [here](https://downloads.lgtm.com/snapshots/cpp/libjpeg-turbo/libjpeg-turbo-revision-0fa7850aeb273204acd57be11f328b2be5d97dc6.zip), and one that contains the fix is [here](https://downloads.lgtm.com/snapshots/cpp/libjpeg-turbo/libjpeg-turbo-revision-d5f281b734425fc1d930ff2c3f8441aad731343e.zip).
+A snapshot of libjpeg-turbo from before the fix is [here](https://github.com/github/securitylab/releases/download/lipjpeg-turbo-codeql-database/libjpeg-turbo-revision-0fa7850aeb273204acd57be11f328b2be5d97dc6.zip), and one that contains the fix is [here](https://github.com/github/securitylab/releases/download/lipjpeg-turbo-codeql-database-patched/libjpeg-turbo-revision-d5f281b734425fc1d930ff2c3f8441aad731343e.zip).
 
 The first five QL files develop a query that flags exactly the fixed accesses on the former snapshot, and nothing on the latter; the last query is a generalisation that finds a new instance of the same problem. All queries are run on the fixed snapshot, except when stated otherwise.
 
@@ -11,6 +11,6 @@ The first five QL files develop a query that flags exactly the fixed accesses on
   - 02b_find_guarded_colormap_index_working.ql: The previous query doesn't actually work, since `ERREXIT` isn't recognised as being a non-returning macro. This query fixes that.
   - 03_find_unguarded_colormap_index.ql: Flipping the logic around, we now look for _unguarded_ indexing. This gives a few false positives in cases where `cmap_length` isn't used. There is still a guard in these cases, but it's against a parameter that happens to contain the size of the colour map.
   - 04_find_unguarded_colormap_no_fps.ql: Add inter-procedural tracking to reason about the flow of colour maps and their sizes. This eliminates the remaining FPs on the fixed snapshot, and gives the expected results on the original snapshot.
-  - 05_find_unguarded_colormap_generalised.ql: By removing the hardcoded references to `_bmp_source_struct`, we get a more general query that looks for other unguarded indexes into colour maps. This gives yet more false positives, since there are a few other guarding patterns, but the first three results are actually true positives, which we [reported](https://github.com/libjpeg-turbo/libjpeg-turbo/issues/295). A snapshot with these results fixed is available [here](https://downloads.lgtm.com/snapshots/cpp/libjpeg-turbo/libjpeg-turbo-revision-d00d7d8c194e587ed10a395e0f307ce9dddf5687.zip).
+  - 05_find_unguarded_colormap_generalised.ql: By removing the hardcoded references to `_bmp_source_struct`, we get a more general query that looks for other unguarded indexes into colour maps. This gives yet more false positives, since there are a few other guarding patterns, but the first three results are actually true positives, which we [reported](https://github.com/libjpeg-turbo/libjpeg-turbo/issues/295). A snapshot with these results fixed is available [here](https://github.com/github/securitylab/releases/download/lipjpeg-turbo-codeql-database-patched/libjpeg-turbo-revision-d00d7d8c194e587ed10a395e0f307ce9dddf5687.zip).
 
 Note that the final query is somewhat non-trivial (>100 LoC, uses global value numbering, guards and inter-procedural flow), so it's perhaps best used with an audience that has seen some simple QL before.
diff --git a/CodeQL_Queries/cpp/libssh2_eating_error_codes/README.md b/CodeQL_Queries/cpp/libssh2_eating_error_codes/README.md
@@ -1,9 +1,9 @@
 # Eating error codes in libssh2
 
-Download this [snapshot](https://downloads.lgtm.com/snapshots/cpp/libssh2/libssh2_libssh2_C_C++_38bf7ce.zip) for the demo.
+Download this [snapshot](https://github.com/github/securitylab/releases/download/libssh2-codeql-database/libssh2_libssh2_C_C++_38bf7ce.zip) for the demo.
 
 This demo shows how to develop, step-by-step, the query from the [blog post](https://blog.semmle.com/libssh2-integer-overflow/) about libssh2 CVE-2019-13115. This query did not find the bug that caused the CVE. It is instead about doing variant analysis on a bug that we noticed on the development branch of libssh2. We sent the query results to the libssh2 development team and they were able to fix all the variants before the next version of libssh2 was released.
 
-[This](https://lgtm.com/projects/g/libssh2/libssh2/snapshot/6e2f5563c80521b3cde72a6fcdb675c2e085f9cf/files/src/hostkey.c?sort=name&dir=ASC&mode=heatmap&__hstc=70225743.5fa8704c8874c6eafaef219923a26734.1534954774206.1564532078978.1564925733575.72&__hssc=70225743.2.1565139962633&__hsfp=997709570#L677) is an example of the bug. The problem is that `_libssh2_get_c_string` returns a negative integer as an error code, but the type of `r_len` is `unsigned int`, so the error code is accidentally ignored.
+The problem is that `_libssh2_get_c_string` returns a negative integer as an error code, but the type of `r_len` is `unsigned int`, so the error code is accidentally ignored.
 
 For a shorter demo, stop at step 02. Steps 03 and 04 make the query more sophisticated by adding local data flow and range analysis.
diff --git a/CodeQL_Queries/cpp/rsyslog_CVE-2018-1000140/README.md b/CodeQL_Queries/cpp/rsyslog_CVE-2018-1000140/README.md
@@ -1,5 +1,5 @@
-[Blog post](https://lgtm.com/blog/rsyslog_snprintf_CVE-2018-1000140).
+[Blog post](https://securitylab.github.com/research/librelp-buffer-overflow-cve-2018-1000140/).
 
-This bug was found by one of our [default queries](https://lgtm.com/rules/1505913226124/). However, it also makes a good example of using QL interactively. The queries in this directory show how you can interactively develop the query.
+This bug was found by one of [CodeQL](https://codeql.github.com/) default queries. However, it also makes a good example of using QL interactively. The queries in this directory show how you can interactively develop the query.
 
-Use [this snapshot](https://downloads.lgtm.com/snapshots/cpp/rsyslog/rsyslog/rsyslog-all-revision-2018-April-27--14-12-31.zip).
+Use [this snapshot](https://github.com/github/securitylab/releases/download/rsyslog-codeql-database/rsyslog-all-revision-2018-April-27--14-12-31.zip).
diff --git a/CodeQL_Queries/cpp/rsyslog_CVE-2018-1000140/Video/rsyslog.srt b/CodeQL_Queries/cpp/rsyslog_CVE-2018-1000140/Video/rsyslog.srt
@@ -1168,7 +1168,7 @@ which is now included
 
 285
 00:16:24,478 --> 00:16:28,858
-in our default suite on lgtm.com.
+in our default suite on lgtm.com (NOW DEPRECATED).
 
 286
 00:16:29,340 --> 00:16:32,231
diff --git a/CodeQL_Queries/csharp/ZipSlip/README.md b/CodeQL_Queries/csharp/ZipSlip/README.md
@@ -2,7 +2,7 @@
 
 ## Snapshot
 
-Use [this snapshot](http://downloads.lgtm.com/snapshots/csharp/microsoft/powershell/PowerShell_PowerShell_csharp-srcVersion_450d884668ca477c6581ce597958f021fac30bff-dist_odasa-lgtm-2018-09-11-e5cbe16-linux64.zip)
+Use [this snapshot](https://github.com/github/securitylab/releases/download/powershell-codeql-database/PowerShell_PowerShell_csharp-srcVersion_450d884668ca477c6581ce597958f021fac30bff-dist_odasa-lgtm-2018-09-11-e5cbe16-linux64.zip)
 of PowerShell.
 
 ## Introduction
@@ -15,14 +15,12 @@ they had written a basic query and run it against a number of critical codebases
 Because Semmle has a close working relationship with Microsoft, we then helped Microsoft to refine
 that query further and submit it as a [pull request](https://github.com/Semmle/ql/pull/54) against our open source QL repository.
 
-It was deployed to [LGTM.com](https://lgtm.com) within 2 weeks where it was run over thousands of open source C# projects.
+It was deployed to the now deprecated LGTM website within 2 weeks where it was run over thousands of open source C# projects.
 
-Here are some [sample results](https://lgtm.com/rules/1506511188430/alerts/) for the ZipSlip query. 
-One of those projects was Microsoft PowerShell.
+The CodeQL ZipSlip query found a vulnerability in Microsoft PowerShell.
 
 As a result of this query, [a senior Microsoft engineer](https://github.com/TravisEz13)
-fixed this vulnerability in November 2018 in
-[this PR](https://lgtm.com/projects/g/PowerShell/PowerShell/rev/b39a41109d86d9ba75f966e2d7b52b81fa629150).
+fixed this vulnerability in November 2018.
 
 So how did they do it?
 
@@ -48,5 +46,24 @@ This uses a global taint tracking configuration.
 
 # Final query
 
-The [final query](https://lgtm.com/rules/1506511188430/) includes query help, and identifies various other sources and sinks,
-but uses the same general structure. It also includes metadata for LGTM.
+The final query below includes query help, and identifies various other sources and sinks,
+but uses the same general structure.
+
+```ql
+using System.IO;
+using System.IO.Compression;
+class Good
+{
+    public static void WriteToDirectory(ZipArchiveEntry entry,
+                                        string destDirectory)
+    {
+        string destFileName = Path.GetFullPath(Path.Combine(destDirectory, entry.FullName));
+        string fullDestDirPath = Path.GetFullPath(destDirectory + Path.DirectorySeparatorChar);
+        if (!destFileName.StartsWith(fullDestDirPath)) {
+            throw new System.InvalidOperationException("Entry is outside the target dir: " +
+                                                                                 destFileName);
+        }
+        entry.ExtractToFile(destFileName);
+    }
+}
+```
diff --git a/CodeQL_Queries/java/Apache_Struts_CVE-2017-9805/README.md b/CodeQL_Queries/java/Apache_Struts_CVE-2017-9805/README.md
@@ -1,6 +1,6 @@
-[Blog post](https://lgtm.com/blog/apache_struts_CVE-2017-9805)
+[Blog post](https://securitylab.github.com/research/apache-struts-vulnerability-cve-2017-9805/)
 
-[This snapshot](https://downloads.lgtm.com/snapshots/java/apache/struts/apache-struts-91ae344-CVE-2017-9805.zip) has the bug. Also, Mo has greated a copy of the project so that you can see [the result](https://lgtm.com/projects/g/mmosemmle/struts_9805/alerts/?mode=list&id=java%2Funsafe-deserialization) on [lgtm.com](https://lgtm.com/projects/g/mmosemmle/struts_9805).
+[This snapshot](https://github.com/github/securitylab/releases/download/apache-struts-codeql-database/apache-struts-91ae344-CVE-2017-9805.zip) has the bug.
 
 This directory contains a copy of `UnsafeDeserialization.qll`, because I get a syntax error when I try to do `import Security.CWE.CWE-502.UnsafeDeserialization`.
 
diff --git a/CodeQL_Queries/java/Apache_Struts_CVE-2018-11776/README.md b/CodeQL_Queries/java/Apache_Struts_CVE-2018-11776/README.md
@@ -1,8 +1,8 @@
 # Apache Struts CVE-2018-11776
 
-[Blog post](https://lgtm.com/blog/apache_struts_CVE-2018-11776)
+[Blog post](https://securitylab.github.com/research/apache-struts-CVE-2018-11776/)
 
-[This snapshot](https://downloads.lgtm.com/snapshots/java/apache/struts/apache-struts-7fd1622-CVE-2018-11776.zip) has the bug.
+[This snapshot](https://github.com/github/securitylab/releases/download/apache-struts-CVE-2018-11776-codeql-database/apache-struts-7fd1622-CVE-2018-11776.zip) has the bug.
 
 The queries in this directory are slightly simplified to make the demo easier to follow. As a result, they don't find as many variants as the query described in the blog post. The full query can be found [here](https://github.com/Semmle/SecurityQueries/blob/e5c2be7d5eec46cd5a4a8ebdbe8cb63be2e36665/semmle-security-java/queries/struts/cve_2018_11776/final.ql).
 
diff --git a/CodeQL_Queries/javascript/Etherpad_CVE-2018-6835/06_DataFlow_With_Sanitizer.ql b/CodeQL_Queries/javascript/Etherpad_CVE-2018-6835/06_DataFlow_With_Sanitizer.ql
@@ -89,10 +89,7 @@ class IsVarNameSanitizer extends TaintTracking::AdditionalSanitizerGuardNode, Da
   }
 }
 
-// The vulnerability was fixed on 2018-03-23 by adding a call to isValidJSONPName:
-//
-// https://lgtm.com/projects/g/ether/etherpad-lite/rev/dd7894d3c9389a000d11d3a89962d9fcc9c6c44b
-//
+// The vulnerability was fixed on 2018-03-23 by adding a call to isValidJSONPName.
 // This version of the query adds a sanitizer to exclude those results.
 from Configuration xss, DataFlow::PathNode source, DataFlow::PathNode sink
 where xss.hasFlowPath(source, sink)
diff --git a/CodeQL_Queries/javascript/Etherpad_CVE-2018-6835/README.md b/CodeQL_Queries/javascript/Etherpad_CVE-2018-6835/README.md
@@ -1,5 +1,5 @@
-[Blog post](https://lgtm.com/blog/etherpad_CVE-2018-6835)
+[Blog post](https://securitylab.github.com/research/etherpad-reflected-file-download/)
 
-[This snapshot](https://downloads.lgtm.com/snapshots/javascript/ether/etherpad-lite/Etherpad_1.6.2.zip) has the vulnerability.
+[This snapshot](https://github.com/github/securitylab/releases/download/etherpad-vulnerable-codeql-database/Etherpad_1.6.2.zip) has the vulnerability.
 
-For the final query, which shows how to detect the sanitization function after the bug was fixed, use [this snapshot](https://downloads.lgtm.com/snapshots/javascript/ether/etherpad-lite/Etherpad_42e0646327527ff0db7bcbd93fb9d16ff738905b.zip).
+For the final query, which shows how to detect the sanitization function after the bug was fixed, use [this snapshot](https://github.com/github/securitylab/releases/download/etherpad-patched-codeql-database/Etherpad_42e0646327527ff0db7bcbd93fb9d16ff738905b.zip).
diff --git a/CodeQL_Queries/javascript/Etherpad_CVE-2018-6835/alternative/README.md b/CodeQL_Queries/javascript/Etherpad_CVE-2018-6835/alternative/README.md
diff --git a/SecurityExploits/apple/darwin-xnu/DTrace/CVE-2017-13782/README.md b/SecurityExploits/apple/darwin-xnu/DTrace/CVE-2017-13782/README.md
diff --git a/SecurityExploits/apple/darwin-xnu/DTrace/CVE-2017-13782/cve-2017-13782-poc.c b/SecurityExploits/apple/darwin-xnu/DTrace/CVE-2017-13782/cve-2017-13782-poc.c
diff --git a/SecurityExploits/apple/darwin-xnu/icmp_error_CVE-2018-4407/README.md b/SecurityExploits/apple/darwin-xnu/icmp_error_CVE-2018-4407/README.md
diff --git a/SecurityExploits/apple/darwin-xnu/nfs_vfsops_CVE-2018-4259/README.md b/SecurityExploits/apple/darwin-xnu/nfs_vfsops_CVE-2018-4259/README.md
diff --git a/SecurityExploits/apple/darwin-xnu/packet_mangler_CVE-2017-13904/README.md b/SecurityExploits/apple/darwin-xnu/packet_mangler_CVE-2017-13904/README.md
diff --git a/SecurityExploits/rsyslog/CVE-2018-1000140_snprintf_librelp/README.md b/SecurityExploits/rsyslog/CVE-2018-1000140_snprintf_librelp/README.md

Original file line number	Diff line number	Diff line change
`@@ -10,7 +10,7 @@`
`10`	`10`	`/*`
`11`	`11`	`* This query is explained in detail in this blog post:`
`12`	`12`	`*`
`13`		`- * https://lgtm.com/blog/apple_xnu_icmp_error_CVE-2018-4407`
	`13`	`+ * https://securitylab.github.com/research/apple-xnu-icmp-error-CVE-2018-4407/`
`14`	`14`	`*`
`15`	`15`	* It is based on the assumption that the function `m_mtod`, which returns
`16`	`16`	* a pointer to the data stored in an `mbuf`, often returns a buffer