update testing cves with new bippy output format.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

4 files changed, 57 insertions, 29 deletions

diff --git a/cve/published/2023/CVE-2023-1851.json b/cve/published/2023/CVE-2023-1851.json
index aa577872..7e4f8735 100644
--- a/cve/published/2023/CVE-2023-1851.json
+++ b/cve/published/2023/CVE-2023-1851.json
@@ -7,7 +7,7 @@
          "descriptions": [
             {
                "lang": "en",
-               "value": "nfc: llcp_core: Hold a ref to llcp_local->dev when holding a ref to llcp_local\n\nllcp_sock_sendmsg() calls nfc_llcp_send_ui_frame() which in turn calls\nnfc_alloc_send_skb(), which accesses the nfc_dev from the llcp_sock for\ngetting the headroom and tailroom needed for skb allocation.\n\nParallelly the nfc_dev can be freed, as the refcount is decreased via\nnfc_free_device(), leading to a UAF reported by Syzkaller, which can\nbe summarized as follows:\n\n(1) llcp_sock_sendmsg() -> nfc_llcp_send_ui_frame()\n\t-> nfc_alloc_send_skb() -> Dereference *nfc_dev\n(2) virtual_ncidev_close() -> nci_free_device() -> nfc_free_device()\n\t-> put_device() -> nfc_release() -> Free *nfc_dev\n\nWhen a reference to llcp_local is acquired, we do not acquire the same\nfor the nfc_dev. This leads to freeing even when the llcp_local is in\nuse, and this is the case with the UAF described above too.\n\nThus, when we acquire a reference to llcp_local, we should acquire a\nreference to nfc_dev, and release the references appropriately later.\n\nReferences for llcp_local is initialized in nfc_llcp_register_device()\n(which is called by nfc_register_device()). Thus, we should acquire a\nreference to nfc_dev there.\n\nnfc_unregister_device() calls nfc_llcp_unregister_device() which in\nturn calls nfc_llcp_local_put(). Thus, the reference to nfc_dev is\nappropriately released later.\n\nReported-and-tested-by: syzbot+bbe84a4010eeea00982d@syzkaller.appspotmail.com\nCloses: https://syzkaller.appspot.com/bug?extid=bbe84a4010eeea00982d\nFixes: c7aa12252f51 (\"NFC: Take a reference on the LLCP local pointer when creating a socket\")\nReviewed-by: Suman Ghosh <sumang@marvell.com>\nSigned-off-by: Siddh Raman Pant <code@siddh.me>\nReviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>\nSigned-off-by: David S. Miller <davem@davemloft.net>"
+               "value": "nfc: llcp_core: Hold a ref to llcp_local->dev when holding a ref to llcp_local\n\nllcp_sock_sendmsg() calls nfc_llcp_send_ui_frame() which in turn calls\nnfc_alloc_send_skb(), which accesses the nfc_dev from the llcp_sock for\ngetting the headroom and tailroom needed for skb allocation.\n\nParallelly the nfc_dev can be freed, as the refcount is decreased via\nnfc_free_device(), leading to a UAF reported by Syzkaller, which can\nbe summarized as follows:\n\n(1) llcp_sock_sendmsg() -> nfc_llcp_send_ui_frame()\n\t-> nfc_alloc_send_skb() -> Dereference *nfc_dev\n(2) virtual_ncidev_close() -> nci_free_device() -> nfc_free_device()\n\t-> put_device() -> nfc_release() -> Free *nfc_dev\n\nWhen a reference to llcp_local is acquired, we do not acquire the same\nfor the nfc_dev. This leads to freeing even when the llcp_local is in\nuse, and this is the case with the UAF described above too.\n\nThus, when we acquire a reference to llcp_local, we should acquire a\nreference to nfc_dev, and release the references appropriately later.\n\nReferences for llcp_local is initialized in nfc_llcp_register_device()\n(which is called by nfc_register_device()). Thus, we should acquire a\nreference to nfc_dev there.\n\nnfc_unregister_device() calls nfc_llcp_unregister_device() which in\nturn calls nfc_llcp_local_put(). Thus, the reference to nfc_dev is\nappropriately released later."
             }
          ],
          "affected": [
@@ -74,7 +74,7 @@
          ],
          "title": "nfc: llcp_core: Hold a ref to llcp_local->dev when holding a ref to llcp_local",
          "x_generator": {
-            "engine": "bippy-7de06c7ff7c8"
+            "engine": "bippy-92010c6125e9"
          }
       }
    },
diff --git a/cve/published/2023/CVE-2023-1851.mbox b/cve/published/2023/CVE-2023-1851.mbox
index 35117dc2..036d3562 100644
--- a/cve/published/2023/CVE-2023-1851.mbox
+++ b/cve/published/2023/CVE-2023-1851.mbox
@@ -1,7 +1,8 @@
 From: Linux Kernel CVE team <cve@kernel.org>
 Subject: CVE-2023-1851: nfc: llcp_core: Hold a ref to llcp_local->dev when holding a ref to llcp_local
 
-CVE-2023-1851 has been assigned for the following issue:
+Description
+===========
 
 nfc: llcp_core: Hold a ref to llcp_local->dev when holding a ref to llcp_local
 
@@ -33,13 +34,32 @@ nfc_unregister_device() calls nfc_llcp_unregister_device() which in
 turn calls nfc_llcp_local_put(). Thus, the reference to nfc_dev is
 appropriately released later.
 
-Reported-and-tested-by: syzbot+bbe84a4010eeea00982d@syzkaller.appspotmail.com
-Closes: https://syzkaller.appspot.com/bug?extid=bbe84a4010eeea00982d
-Fixes: c7aa12252f51 ("NFC: Take a reference on the LLCP local pointer when creating a socket")
-Reviewed-by: Suman Ghosh <sumang@marvell.com>
-Signed-off-by: Siddh Raman Pant <code@siddh.me>
-Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
-Signed-off-by: David S. Miller <davem@davemloft.net>
+The Linux kernel CVE team has assigned CVE-2023-1851 to this issue.
 
-Affected versions:
 
+Mitigation
+==========
+
+The individual change to resolve this issue can be found at:
+	https://git.kernel.org/torvalds/c/c95f919567d6f1914f13350af61a1b044ac85014
+
+
+Affected versions
+=================
+	Issue introduced in 3.6 and fixed in 4.14.336
+	Issue introduced in 3.6 and fixed in 4.19.305
+	Issue introduced in 3.6 and fixed in 5.4.267
+	Issue introduced in 3.6 and fixed in 5.10.208
+	Issue introduced in 3.6 and fixed in 5.15.147
+	Issue introduced in 3.6 and fixed in 6.1.72
+	Issue introduced in 3.6 and fixed in 6.6.11
+	Issue introduced in 3.6 and fixed in 6.7
+
+
+Recomendation
+=============
+The Linux kernel CVE team recommends that you update to the latest
+stable kernel version for this, and many other bugfixes.  Individual
+changes are not tested alone, but rather are part of a larger kernel
+release.  Cherry-picking individual commits is not recommended or
+supported by the Linux kernel community at all.
diff --git a/cve/published/2024/CVE-2024-0052.json b/cve/published/2024/CVE-2024-0052.json
index d527f033..1505a17b 100644
--- a/cve/published/2024/CVE-2024-0052.json
+++ b/cve/published/2024/CVE-2024-0052.json
@@ -7,7 +7,7 @@
          "descriptions": [
             {
                "lang": "en",
-               "value": "mm/memory_hotplug: fix memmap_on_memory sysfs value retrieval\n\nset_memmap_mode() stores the kernel parameter memmap mode as an integer. \nHowever, the get_memmap_mode() function utilizes param_get_bool() to fetch\nthe value as a boolean, leading to potential endianness issue.  On\nBig-endian architectures, the memmap_on_memory is consistently displayed\nas 'N' regardless of its actual status.\n\nTo address this endianness problem, the solution involves obtaining the\nmode as an integer.  This adjustment ensures the proper display of the\nmemmap_on_memory parameter, presenting it as one of the following options:\nForce, Y, or N.\n\nLink: https://lkml.kernel.org/r/20240110140127.241451-1-sumanthk@linux.ibm.com\nFixes: 2d1f649c7c08 (\"mm/memory_hotplug: support memmap_on_memory when memmap is not aligned to pageblocks\")\nSigned-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>\nSuggested-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>\nAcked-by: David Hildenbrand <david@redhat.com>\nCc: Alexander Gordeev <agordeev@linux.ibm.com>\nCc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>\nCc: Heiko Carstens <hca@linux.ibm.com>\nCc: Michal Hocko <mhocko@suse.com>\nCc: Oscar Salvador <osalvador@suse.de>\nCc: Vasily Gorbik <gor@linux.ibm.com>\nCc: <stable@vger.kernel.org>\t[6.6+]\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>"
+               "value": "mm/memory_hotplug: fix memmap_on_memory sysfs value retrieval\n\nset_memmap_mode() stores the kernel parameter memmap mode as an integer. \nHowever, the get_memmap_mode() function utilizes param_get_bool() to fetch\nthe value as a boolean, leading to potential endianness issue.  On\nBig-endian architectures, the memmap_on_memory is consistently displayed\nas 'N' regardless of its actual status.\n\nTo address this endianness problem, the solution involves obtaining the\nmode as an integer.  This adjustment ensures the proper display of the\nmemmap_on_memory parameter, presenting it as one of the following options:\nForce, Y, or N."
             }
          ],
          "affected": [
@@ -38,7 +38,7 @@
          ],
          "title": "mm/memory_hotplug: fix memmap_on_memory sysfs value retrieval",
          "x_generator": {
-            "engine": "bippy-7de06c7ff7c8"
+            "engine": "bippy-92010c6125e9"
          }
       }
    },
diff --git a/cve/published/2024/CVE-2024-0052.mbox b/cve/published/2024/CVE-2024-0052.mbox
index fa7a1ea0..0760e017 100644
--- a/cve/published/2024/CVE-2024-0052.mbox
+++ b/cve/published/2024/CVE-2024-0052.mbox
@@ -1,7 +1,8 @@
 From: Linux Kernel CVE team <cve@kernel.org>
 Subject: CVE-2024-0052: mm/memory_hotplug: fix memmap_on_memory sysfs value retrieval
 
-CVE-2024-0052 has been assigned for the following issue:
+Description
+===========
 
 mm/memory_hotplug: fix memmap_on_memory sysfs value retrieval
 
@@ -16,19 +17,26 @@ mode as an integer.  This adjustment ensures the proper display of the
 memmap_on_memory parameter, presenting it as one of the following options:
 Force, Y, or N.
 
-Link: https://lkml.kernel.org/r/20240110140127.241451-1-sumanthk@linux.ibm.com
-Fixes: 2d1f649c7c08 ("mm/memory_hotplug: support memmap_on_memory when memmap is not aligned to pageblocks")
-Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
-Suggested-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
-Acked-by: David Hildenbrand <david@redhat.com>
-Cc: Alexander Gordeev <agordeev@linux.ibm.com>
-Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
-Cc: Heiko Carstens <hca@linux.ibm.com>
-Cc: Michal Hocko <mhocko@suse.com>
-Cc: Oscar Salvador <osalvador@suse.de>
-Cc: Vasily Gorbik <gor@linux.ibm.com>
-Cc: <stable@vger.kernel.org>	[6.6+]
-Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
-
-Affected versions:
+The Linux kernel CVE team has assigned CVE-2024-0052 to this issue.
 
+
+Mitigation
+==========
+
+The individual change to resolve this issue can be found at:
+	https://git.kernel.org/torvalds/c/11684134140bb708b6e6de969a060535630b1b53
+
+
+Affected versions
+=================
+	Issue introduced in 6.6 and fixed in 6.6.13
+	Issue introduced in 6.6 and fixed in 6.7.1
+
+
+Recomendation
+=============
+The Linux kernel CVE team recommends that you update to the latest
+stable kernel version for this, and many other bugfixes.  Individual
+changes are not tested alone, but rather are part of a larger kernel
+release.  Cherry-picking individual commits is not recommended or
+supported by the Linux kernel community at all.