Auto-Update: 2025-05-04T02:00:13.788943+00:00

CVE-2015/CVE-2015-20xx/CVE-2015-2079.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "cve@mitre.org",
   "published": "2025-04-28T15:15:44.007",
   "lastModified": "2025-04-29T13:52:10.697",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2020/CVE-2020-367xx/CVE-2020-36790.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: fix a memory leak\n\nWe forgot to free new_model_number"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: corrige una p\u00e9rdida de memoria Olvidamos liberar new_model_number"
     }
   ],
   "metrics": {},

CVE-2021/CVE-2021-286xx/CVE-2021-28656.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "security@apache.org",
   "published": "2024-04-09T10:15:07.610",
   "lastModified": "2024-11-21T06:00:02.420",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-472xx/CVE-2021-47208.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "cve@mitre.org",
   "published": "2024-04-08T00:15:07.920",
   "lastModified": "2025-03-20T14:15:14.867",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-472xx/CVE-2021-47293.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:17.243",
   "lastModified": "2024-11-21T06:35:48.817",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-472xx/CVE-2021-47294.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:17.323",
   "lastModified": "2024-11-21T06:35:48.923",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-472xx/CVE-2021-47296.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:17.477",
   "lastModified": "2024-11-21T06:35:49.233",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-473xx/CVE-2021-47304.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:18.110",
   "lastModified": "2024-11-21T06:35:50.293",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-473xx/CVE-2021-47305.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:18.177",
   "lastModified": "2024-11-21T06:35:50.407",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-473xx/CVE-2021-47315.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:18.860",
   "lastModified": "2025-01-24T16:15:28.320",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-473xx/CVE-2021-47317.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:19.007",
   "lastModified": "2024-11-21T06:35:52.117",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-473xx/CVE-2021-47322.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:19.397",
   "lastModified": "2024-11-21T06:35:52.733",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-473xx/CVE-2021-47335.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:20.350",
   "lastModified": "2024-11-21T06:35:54.583",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-473xx/CVE-2021-47336.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:20.437",
   "lastModified": "2024-11-21T06:35:54.710",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-473xx/CVE-2021-47340.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:20.770",
   "lastModified": "2024-11-21T06:35:55.207",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-473xx/CVE-2021-47343.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:20.993",
   "lastModified": "2024-11-21T06:35:55.597",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-473xx/CVE-2021-47351.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:21.553",
   "lastModified": "2024-11-21T06:35:56.860",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-473xx/CVE-2021-47360.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:22.210",
   "lastModified": "2024-11-21T06:35:58.053",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-473xx/CVE-2021-47365.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:22.563",
   "lastModified": "2024-11-21T06:35:59.227",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-473xx/CVE-2021-47366.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:22.633",
   "lastModified": "2024-11-21T06:35:59.473",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-473xx/CVE-2021-47370.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:22.927",
   "lastModified": "2024-11-21T06:36:00.093",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2021/CVE-2021-473xx/CVE-2021-47374.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2024-05-21T15:15:23.223",
   "lastModified": "2024-11-21T06:36:00.700",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-418xx/CVE-2022-41871.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "cve@mitre.org",
   "published": "2025-04-28T16:15:24.853",
   "lastModified": "2025-04-29T13:52:10.697",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-478xx/CVE-2022-47894.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "security@apache.org",
   "published": "2024-04-09T10:15:08.343",
   "lastModified": "2025-02-13T17:15:49.627",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [
     {
       "sourceIdentifier": "security@apache.org",

CVE-2022/CVE-2022-497xx/CVE-2022-49762.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nntfs: check overflow when iterating ATTR_RECORDs\n\nKernel iterates over ATTR_RECORDs in mft record in ntfs_attr_find(). \nBecause the ATTR_RECORDs are next to each other, kernel can get the next\nATTR_RECORD from end address of current ATTR_RECORD, through current\nATTR_RECORD length field.\n\nThe problem is that during iteration, when kernel calculates the end\naddress of current ATTR_RECORD, kernel may trigger an integer overflow bug\nin executing `a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))`.  This\nmay wrap, leading to a forever iteration on 32bit systems.\n\nThis patch solves it by adding some checks on calculating end address\nof current ATTR_RECORD during iteration."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ntfs: desbordamiento de comprobaci\u00f3n al iterar ATTR_RECORDs El kernel itera sobre los ATTR_RECORD en el registro mft en ntfs_attr_find(). Debido a que los ATTR_RECORD est\u00e1n uno al lado del otro, el kernel puede obtener el siguiente ATTR_RECORD desde la direcci\u00f3n final del ATTR_RECORD actual, a trav\u00e9s del campo de longitud del ATTR_RECORD actual. El problema es que durante la iteraci\u00f3n, cuando el kernel calcula la direcci\u00f3n final del ATTR_RECORD actual, el kernel puede desencadenar un error de desbordamiento de enteros al ejecutar `a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))`. Esto puede envolverse, lo que lleva a una iteraci\u00f3n eterna en sistemas de 32 bits. Este parche lo resuelve a\u00f1adiendo algunas comprobaciones en el c\u00e1lculo de la direcci\u00f3n final del ATTR_RECORD actual durante la iteraci\u00f3n."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49763.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nntfs: fix use-after-free in ntfs_attr_find()\n\nPatch series \"ntfs: fix bugs about Attribute\", v2.\n\nThis patchset fixes three bugs relative to Attribute in record:\n\nPatch 1 adds a sanity check to ensure that, attrs_offset field in first\nmft record loading from disk is within bounds.\n\nPatch 2 moves the ATTR_RECORD's bounds checking earlier, to avoid\ndereferencing ATTR_RECORD before checking this ATTR_RECORD is within\nbounds.\n\nPatch 3 adds an overflow checking to avoid possible forever loop in\nntfs_attr_find().\n\nWithout patch 1 and patch 2, the kernel triggersa KASAN use-after-free\ndetection as reported by Syzkaller.\n\nAlthough one of patch 1 or patch 2 can fix this, we still need both of\nthem.  Because patch 1 fixes the root cause, and patch 2 not only fixes\nthe direct cause, but also fixes the potential out-of-bounds bug.\n\n\nThis patch (of 3):\n\nSyzkaller reported use-after-free read as follows:\n==================================================================\nBUG: KASAN: use-after-free in ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597\nRead of size 2 at addr ffff88807e352009 by task syz-executor153/3607\n\n[...]\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:317 [inline]\n print_report.cold+0x2ba/0x719 mm/kasan/report.c:433\n kasan_report+0xb1/0x1e0 mm/kasan/report.c:495\n ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597\n ntfs_attr_lookup+0x1056/0x2070 fs/ntfs/attrib.c:1193\n ntfs_read_inode_mount+0x89a/0x2580 fs/ntfs/inode.c:1845\n ntfs_fill_super+0x1799/0x9320 fs/ntfs/super.c:2854\n mount_bdev+0x34d/0x410 fs/super.c:1400\n legacy_get_tree+0x105/0x220 fs/fs_context.c:610\n vfs_get_tree+0x89/0x2f0 fs/super.c:1530\n do_new_mount fs/namespace.c:3040 [inline]\n path_mount+0x1326/0x1e20 fs/namespace.c:3370\n do_mount fs/namespace.c:3383 [inline]\n __do_sys_mount fs/namespace.c:3591 [inline]\n __se_sys_mount fs/namespace.c:3568 [inline]\n __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n [...]\n </TASK>\n\nThe buggy address belongs to the physical page:\npage:ffffea0001f8d400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7e350\nhead:ffffea0001f8d400 order:3 compound_mapcount:0 compound_pincount:0\nflags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)\nraw: 00fff00000010200 0000000000000000 dead000000000122 ffff888011842140\nraw: 0000000000000000 0000000000040004 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\nMemory state around the buggy address:\n ffff88807e351f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n ffff88807e351f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n>ffff88807e352000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                      ^\n ffff88807e352080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff88807e352100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n==================================================================\n\nKernel will loads $MFT/$DATA's first mft record in\nntfs_read_inode_mount().\n\nYet the problem is that after loading, kernel doesn't check whether\nattrs_offset field is a valid value.\n\nTo be more specific, if attrs_offset field is larger than bytes_allocated\nfield, then it may trigger the out-of-bounds read bug(reported as\nuse-after-free bug) in ntfs_attr_find(), when kernel tries to access the\ncorresponding mft record's attribute.\n\nThis patch solves it by adding the sanity check between attrs_offset field\nand bytes_allocated field, after loading the first mft record."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ntfs: correcci\u00f3n del use-after-free en ntfs_attr_find(). Serie de parches \"ntfs: correcci\u00f3n de errores sobre el atributo\", v2. Este conjunto de parches corrige tres errores relacionados con el atributo en el registro: el parche 1 a\u00f1ade una comprobaci\u00f3n de seguridad para garantizar que el campo attrs_offset en la primera carga de registro MFT desde el disco est\u00e9 dentro de los l\u00edmites. El parche 2 adelanta la comprobaci\u00f3n de los l\u00edmites de ATTR_RECORD para evitar desreferenciarlo antes de comprobar que est\u00e9 dentro de los l\u00edmites. El parche 3 a\u00f1ade una comprobaci\u00f3n de desbordamiento para evitar un posible bucle infinito en ntfs_attr_find(). Sin los parches 1 y 2, el kernel activa la detecci\u00f3n de use-after-free de KASAN, seg\u00fan lo informado por Syzkaller. Aunque uno de los parches 1 o 2 puede solucionar esto, a\u00fan necesitamos ambos. Porque el parche 1 corrige la causa ra\u00edz, y el parche 2 no solo corrige la causa directa, sino que tambi\u00e9n corrige el posible error fuera de los l\u00edmites. Este parche (de 3): Syzkaller inform\u00f3 una lectura de use-after-free de la siguiente manera: ====================================================================== ERROR: KASAN: use-after-free en ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597 Lectura de tama\u00f1o 2 en la direcci\u00f3n ffff88807e352009 por la tarea syz-executor153/3607 [...] Rastreo de llamadas:  __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597 ntfs_attr_lookup+0x1056/0x2070 fs/ntfs/attrib.c:1193 ntfs_read_inode_mount+0x89a/0x2580 fs/ntfs/inode.c:1845 ntfs_fill_super+0x1799/0x9320 fs/ntfs/super.c:2854 mount_bdev+0x34d/0x410 fs/super.c:1400 legacy_get_tree+0x105/0x220 fs/fs_context.c:610 vfs_get_tree+0x89/0x2f0 fs/super.c:1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x1326/0x1e20 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...]  La direcci\u00f3n con errores pertenece a la p\u00e1gina f\u00edsica: page:ffffea0001f8d400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7e350 head:ffffea0001f8d400 order:3 Compound_mapcount:0 Compound_pincount:0 flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000010200 0000000000000000 muerto000000000122 ffff888011842140 raw: 00000000000000000 0000000000040004 00000001ffffffff 0000000000000000 p\u00e1gina volcada porque: kasan: mal acceso detectado Estado de la memoria alrededor de la direcci\u00f3n con errores: ffff88807e351f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88807e351f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc &gt;ffff88807e352000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88807e352080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88807e352100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ====================================================================== El n\u00facleo cargar\u00e1 el primer registro mft de $MFT/$DATA en ntfs_read_inode_mount(). Sin embargo, el problema radica en que, tras la carga, el kernel no comprueba si el campo attrs_offset es un valor v\u00e1lido. M\u00e1s espec\u00edficamente, si el campo attrs_offset es mayor que el campo bytes_allocated, podr\u00eda activarse el error de lectura fuera de los l\u00edmites (reportado como error de use-after-free) en ntfs_attr_find() cuando el kernel intenta acceder al atributo del registro MFT correspondiente. Este parche lo soluciona a\u00f1adiendo la comprobaci\u00f3n de validez entre los campos attrs_offset y bytes_allocated tras cargar el primer registro MFT."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49764.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Prevent bpf program recursion for raw tracepoint probes\n\nWe got report from sysbot [1] about warnings that were caused by\nbpf program attached to contention_begin raw tracepoint triggering\nthe same tracepoint by using bpf_trace_printk helper that takes\ntrace_printk_lock lock.\n\n Call Trace:\n  <TASK>\n  ? trace_event_raw_event_bpf_trace_printk+0x5f/0x90\n  bpf_trace_printk+0x2b/0xe0\n  bpf_prog_a9aec6167c091eef_prog+0x1f/0x24\n  bpf_trace_run2+0x26/0x90\n  native_queued_spin_lock_slowpath+0x1c6/0x2b0\n  _raw_spin_lock_irqsave+0x44/0x50\n  bpf_trace_printk+0x3f/0xe0\n  bpf_prog_a9aec6167c091eef_prog+0x1f/0x24\n  bpf_trace_run2+0x26/0x90\n  native_queued_spin_lock_slowpath+0x1c6/0x2b0\n  _raw_spin_lock_irqsave+0x44/0x50\n  bpf_trace_printk+0x3f/0xe0\n  bpf_prog_a9aec6167c091eef_prog+0x1f/0x24\n  bpf_trace_run2+0x26/0x90\n  native_queued_spin_lock_slowpath+0x1c6/0x2b0\n  _raw_spin_lock_irqsave+0x44/0x50\n  bpf_trace_printk+0x3f/0xe0\n  bpf_prog_a9aec6167c091eef_prog+0x1f/0x24\n  bpf_trace_run2+0x26/0x90\n  native_queued_spin_lock_slowpath+0x1c6/0x2b0\n  _raw_spin_lock_irqsave+0x44/0x50\n  __unfreeze_partials+0x5b/0x160\n  ...\n\nThe can be reproduced by attaching bpf program as raw tracepoint on\ncontention_begin tracepoint. The bpf prog calls bpf_trace_printk\nhelper. Then by running perf bench the spin lock code is forced to\ntake slow path and call contention_begin tracepoint.\n\nFixing this by skipping execution of the bpf program if it's\nalready running, Using bpf prog 'active' field, which is being\ncurrently used by trampoline programs for the same reason.\n\nMoving bpf_prog_inc_misses_counter to syscall.c because\ntrampoline.c is compiled in just for CONFIG_BPF_JIT option.\n\n[1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Impide la recursi\u00f3n del programa bpf para sondas de puntos de seguimiento sin procesar. Recibimos un informe de sysbot [1] sobre advertencias causadas por el programa bpf asociado al punto de seguimiento sin procesar contention_begin, que activaba el mismo punto de seguimiento mediante el auxiliar bpf_trace_printk, que toma el bloqueo trace_printk_lock. Llamada a Trace:  ? trace_event_raw_event_bpf_trace_printk+0x5f/0x90 bpf_trace_printk+0x2b/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 __unfreeze_partials+0x5b/0x160 Esto se puede reproducir adjuntando el programa bpf como punto de seguimiento sin procesar en el punto de seguimiento contention_begin. El programa bpf llama al asistente bpf_trace_printk. Luego, al ejecutar perf bench, el c\u00f3digo de bloqueo de giro se fuerza a tomar la ruta lenta e invocar el punto de seguimiento contention_begin. Esto se soluciona omitiendo la ejecuci\u00f3n del programa bpf si ya se est\u00e1 ejecutando. Se usa el campo \"activo\" del programa bpf, que actualmente usan los programas trampoline por la misma raz\u00f3n. Se traslada bpf_prog_inc_misses_counter a syscall.c, ya que trampoline.c se compila solo para la opci\u00f3n CONFIG_BPF_JIT. [1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t"
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49765.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/9p: use a dedicated spinlock for trans_fd\n\nShamelessly copying the explanation from Tetsuo Handa's suggested\npatch[1] (slightly reworded):\nsyzbot is reporting inconsistent lock state in p9_req_put()[2],\nfor p9_tag_remove() from p9_req_put() from IRQ context is using\nspin_lock_irqsave() on \"struct p9_client\"->lock but trans_fd\n(not from IRQ context) is using spin_lock().\n\nSince the locks actually protect different things in client.c and in\ntrans_fd.c, just replace trans_fd.c's lock by a new one specific to the\ntransport (client.c's protect the idr for fid/tag allocations,\nwhile trans_fd.c's protects its own req list and request status field\nthat acts as the transport's state machine)"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/9p: uso de un spinlock dedicado para trans_fd. Copiando descaradamente la explicaci\u00f3n del parche sugerido por Tetsuo Handa[1] (ligeramente reformulada): syzbot reporta un estado de bloqueo inconsistente en p9_req_put()[2], para p9_tag_remove() desde p9_req_put() desde el contexto IRQ, se usa spin_lock_irqsave() en \"struct p9_client\"->lock, pero trans_fd (no desde el contexto IRQ) usa spin_lock(). Dado que los bloqueos protegen elementos diferentes en client.c y en trans_fd.c, simplemente reemplace el bloqueo de trans_fd.c por uno nuevo espec\u00edfico para el transporte (el de client.c protege el IDR para las asignaciones de FID/etiqueta, mientras que el de trans_fd.c protege su propia lista de solicitudes y el campo de estado de la solicitud, que act\u00faa como la m\u00e1quina de estados del transporte)."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49766.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetlink: Bounds-check struct nlmsgerr creation\n\nIn preparation for FORTIFY_SOURCE doing bounds-check on memcpy(),\nswitch from __nlmsg_put to nlmsg_put(), and explain the bounds check\nfor dealing with the memcpy() across a composite flexible array struct.\nAvoids this future run-time warning:\n\n  memcpy: detected field-spanning write (size 32) of single field \"&errmsg->msg\" at net/netlink/af_netlink.c:2447 (size 16)"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netlink: Creaci\u00f3n de la estructura nlmsgerr con comprobaci\u00f3n de los l\u00edmites. En preparaci\u00f3n para que FORTIFY_SOURCE realice la comprobaci\u00f3n de los l\u00edmites en memcpy(), cambie de __nlmsg_put a nlmsg_put() y explique la comprobaci\u00f3n de los l\u00edmites para procesar memcpy() en una estructura de matriz flexible compuesta. Esto evita esta futura advertencia en tiempo de ejecuci\u00f3n: memcpy: se detect\u00f3 una escritura que abarca campos (tama\u00f1o 32) en un solo campo \"&errmsg->msg\" en net/netlink/af_netlink.c:2447 (tama\u00f1o 16)."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49767.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\n9p/trans_fd: always use O_NONBLOCK read/write\n\nsyzbot is reporting hung task at p9_fd_close() [1], for p9_mux_poll_stop()\n from p9_conn_destroy() from p9_fd_close() is failing to interrupt already\nstarted kernel_read() from p9_fd_read() from p9_read_work() and/or\nkernel_write() from p9_fd_write() from p9_write_work() requests.\n\nSince p9_socket_open() sets O_NONBLOCK flag, p9_mux_poll_stop() does not\nneed to interrupt kernel_read()/kernel_write(). However, since p9_fd_open()\ndoes not set O_NONBLOCK flag, but pipe blocks unless signal is pending,\np9_mux_poll_stop() needs to interrupt kernel_read()/kernel_write() when\nthe file descriptor refers to a pipe. In other words, pipe file descriptor\nneeds to be handled as if socket file descriptor.\n\nWe somehow need to interrupt kernel_read()/kernel_write() on pipes.\n\nA minimal change, which this patch is doing, is to set O_NONBLOCK flag\n from p9_fd_open(), for O_NONBLOCK flag does not affect reading/writing\nof regular files. But this approach changes O_NONBLOCK flag on userspace-\nsupplied file descriptors (which might break userspace programs), and\nO_NONBLOCK flag could be changed by userspace. It would be possible to set\nO_NONBLOCK flag every time p9_fd_read()/p9_fd_write() is invoked, but still\nremains small race window for clearing O_NONBLOCK flag.\n\nIf we don't want to manipulate O_NONBLOCK flag, we might be able to\nsurround kernel_read()/kernel_write() with set_thread_flag(TIF_SIGPENDING)\nand recalc_sigpending(). Since p9_read_work()/p9_write_work() works are\nprocessed by kernel threads which process global system_wq workqueue,\nsignals could not be delivered from remote threads when p9_mux_poll_stop()\n from p9_conn_destroy() from p9_fd_close() is called. Therefore, calling\nset_thread_flag(TIF_SIGPENDING)/recalc_sigpending() every time would be\nneeded if we count on signals for making kernel_read()/kernel_write()\nnon-blocking.\n\n[Dominique: add comment at Christian's suggestion]"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: 9p/trans_fd: syzbot reporta que la tarea se bloquea en p9_fd_close() [1], ya que p9_mux_poll_stop() de p9_conn_destroy() de p9_fd_close() no interrumpe las solicitudes kernel_read() de p9_fd_read() de p9_read_work() o kernel_write() de p9_fd_write() de p9_write_work() ya iniciadas. Dado que p9_socket_open() establece el indicador O_NONBLOCK, p9_mux_poll_stop() no necesita interrumpir kernel_read()/kernel_write(). Sin embargo, dado que p9_fd_open() no establece el indicador O_NONBLOCK, sino que bloquea la tuber\u00eda a menos que la se\u00f1al est\u00e9 pendiente, p9_mux_poll_stop() necesita interrumpir kernel_read()/kernel_write() cuando el descriptor de archivo hace referencia a una tuber\u00eda. En otras palabras, el descriptor de archivo de la tuber\u00eda debe manejarse como si fuera un descriptor de archivo de socket. De alguna manera, necesitamos interrumpir kernel_read()/kernel_write() en las tuber\u00edas. Un cambio m\u00ednimo, que este parche est\u00e1 realizando, es establecer el indicador O_NONBLOCK de p9_fd_open(), ya que el indicador O_NONBLOCK no afecta la lectura/escritura de archivos normales. Pero este enfoque cambia el indicador O_NONBLOCK en los descriptores de archivo proporcionados por el espacio de usuario (lo que podr\u00eda romper los programas del espacio de usuario), y el indicador O_NONBLOCK podr\u00eda ser cambiado por el espacio de usuario. Ser\u00eda posible establecer el indicador O_NONBLOCK cada vez que se invoca p9_fd_read()/p9_fd_write(), pero a\u00fan queda una peque\u00f1a ventana de tiempo para borrar el indicador O_NONBLOCK. Si no queremos manipular el indicador O_NONBLOCK, podr\u00edamos rodear kernel_read()/kernel_write() con set_thread_flag(TIF_SIGPENDING) y recalc_sigpending(). Dado que los trabajos de p9_read_work()/p9_write_work() son procesados por hilos del n\u00facleo que procesan la cola de trabajo global system_wq, no se pudieron enviar se\u00f1ales desde hilos remotos al llamar a p9_mux_poll_stop() de p9_conn_destroy() de p9_fd_close(). Por lo tanto, ser\u00eda necesario llamar a set_thread_flag(TIF_SIGPENDING)/recalc_sigpending() cada vez si dependemos de se\u00f1ales para que kernel_read()/kernel_write() sea no bloqueante. [Dominique: a\u00f1adir comentario a la sugerencia de Christian]"
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49768.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\n9p: trans_fd/p9_conn_cancel: drop client lock earlier\n\nsyzbot reported a double-lock here and we no longer need this\nlock after requests have been moved off to local list:\njust drop the lock earlier."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: 9p: trans_fd/p9_conn_cancel: eliminar el bloqueo del cliente anteriormente. syzbot inform\u00f3 un bloqueo doble aqu\u00ed y ya no necesitamos este bloqueo despu\u00e9s de que las solicitudes se hayan movido a la lista local: simplemente elimine el bloqueo anteriormente."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49769.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Check sb_bsize_shift after reading superblock\n\nFuzzers like to scribble over sb_bsize_shift but in reality it's very\nunlikely that this field would be corrupted on its own. Nevertheless it\nshould be checked to avoid the possibility of messy mount errors due to\nbad calculations. It's always a fixed value based on the block size so\nwe can just check that it's the expected value.\n\nTested with:\n\n    mkfs.gfs2 -O -p lock_nolock /dev/vdb\n    for i in 0 -1 64 65 32 33; do\n        gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb\n        mount /dev/vdb /mnt/test && umount /mnt/test\n    done\n\nBefore this patch we get a withdraw after\n\n[   76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block\n[   76.413681]   bh = 19 (type: exp=5, found=4)\n[   76.413681]   function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492\n\nand with UBSAN configured we also get complaints like\n\n[   76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19\n[   76.373815] shift exponent 4294967287 is too large for 64-bit type 'long unsigned int'\n\nAfter the patch, these complaints don't appear, mount fails immediately\nand we get an explanation in dmesg."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gfs2: Comprobaci\u00f3n de sb_bsize_shift tras leer el superbloque. A los fuzzers les gusta manipular sb_bsize_shift, pero en realidad es muy improbable que este campo se corrompa por s\u00ed solo. Sin embargo, conviene comprobarlo para evitar errores de montaje problem\u00e1ticos debido a c\u00e1lculos err\u00f3neos. Siempre es un valor fijo basado en el tama\u00f1o del bloque, por lo que podemos comprobar que sea el valor esperado. Probado con: mkfs.gfs2 -O -p lock_nolock /dev/vdb for i in 0 -1 64 65 32 33; Antes de este parche obtenemos una retirada despu\u00e9s de [ 76.413681] gfs2: fsid=loop0.0: fatal: bloque de metadatos no v\u00e1lido [ 76.413681] bh = 19 (tipo: exp=5, encontrado=4) [ 76.413681] funci\u00f3n = gfs2_meta_buffer, archivo = fs/gfs2/meta_io.c, l\u00ednea = 492 y con UBSAN configurado tambi\u00e9n obtenemos quejas como [ 76.373395] UBSAN: cambio fuera de los l\u00edmites en fs/gfs2/ops_fstype.c:295:19 [ 76.373815] cambio El exponente 4294967287 es demasiado grande para el tipo de 64 bits 'long unsigned int'. Despu\u00e9s del parche, estas quejas no aparecen, el montaje falla inmediatamente y obtenemos una explicaci\u00f3n en dmesg."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49770.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nceph: avoid putting the realm twice when decoding snaps fails\n\nWhen decoding the snaps fails it maybe leaving the 'first_realm'\nand 'realm' pointing to the same snaprealm memory. And then it'll\nput it twice and could cause random use-after-free, BUG_ON, etc\nissues."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: evita repetir el dominio cuando falla la decodificaci\u00f3n de snaps. Al fallar la decodificaci\u00f3n de snaps, puede que \"first_realm\" y \"realm\" apunten a la misma memoria de snaprealm. En ese caso, lo repetir\u00e1, lo que podr\u00eda causar problemas aleatorios de use-after-free, BUG_ON, etc."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49771.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm ioctl: fix misbehavior if list_versions races with module loading\n\n__list_versions will first estimate the required space using the\n\"dm_target_iterate(list_version_get_needed, &needed)\" call and then will\nfill the space using the \"dm_target_iterate(list_version_get_info,\n&iter_info)\" call. Each of these calls locks the targets using the\n\"down_read(&_lock)\" and \"up_read(&_lock)\" calls, however between the first\nand second \"dm_target_iterate\" there is no lock held and the target\nmodules can be loaded at this point, so the second \"dm_target_iterate\"\ncall may need more space than what was the first \"dm_target_iterate\"\nreturned.\n\nThe code tries to handle this overflow (see the beginning of\nlist_version_get_info), however this handling is incorrect.\n\nThe code sets \"param->data_size = param->data_start + needed\" and\n\"iter_info.end = (char *)vers+len\" - \"needed\" is the size returned by the\nfirst dm_target_iterate call; \"len\" is the size of the buffer allocated by\nuserspace.\n\n\"len\" may be greater than \"needed\"; in this case, the code will write up\nto \"len\" bytes into the buffer, however param->data_size is set to\n\"needed\", so it may write data past the param->data_size value. The ioctl\ninterface copies only up to param->data_size into userspace, thus part of\nthe result will be truncated.\n\nFix this bug by setting \"iter_info.end = (char *)vers + needed;\" - this\nguarantees that the second \"dm_target_iterate\" call will write only up to\nthe \"needed\" buffer and it will exit with \"DM_BUFFER_FULL_FLAG\" if it\noverflows the \"needed\" space - in this case, userspace will allocate a\nlarger buffer and retry.\n\nNote that there is also a bug in list_version_get_needed - we need to add\n\"strlen(tt->name) + 1\" to the needed size, not \"strlen(tt->name)\"."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm ioctl: se corrige el comportamiento incorrecto si list_versions se acelera al cargar m\u00f3dulos. __list_versions primero estimar\u00e1 el espacio requerido mediante la llamada \"dm_target_iterate(list_version_get_needed, &needed)\" y luego llenar\u00e1 el espacio mediante la llamada \"dm_target_iterate(list_version_get_info, &iter_info)\". Cada una de estas llamadas bloquea los destinos mediante las llamadas \"down_read(&_lock)\" y \"up_read(&_lock)\". Sin embargo, entre la primera y la segunda llamada \"dm_target_iterate\" no se mantiene el bloqueo y los m\u00f3dulos de destino se pueden cargar en este punto, por lo que la segunda llamada \"dm_target_iterate\" podr\u00eda necesitar m\u00e1s espacio que el devuelto por la primera llamada \"dm_target_iterate\". El c\u00f3digo intenta gestionar este desbordamiento (v\u00e9ase el comienzo de list_version_get_info), pero esta gesti\u00f3n es incorrecta. El c\u00f3digo establece \"param->data_size = param->data_start + needed\" y \"iter_info.end = (char *)vers+len\": \"needed\" es el tama\u00f1o devuelto por la primera llamada a dm_target_iterate; \"len\" es el tama\u00f1o del b\u00fafer asignado por el espacio de usuario. \"len\" puede ser mayor que \"needed\"; en este caso, el c\u00f3digo escribir\u00e1 hasta \"len\" bytes en el b\u00fafer; sin embargo, param->data_size se establece en \"needed\", por lo que podr\u00eda escribir datos que superen el valor de param->data_size. La interfaz ioctl solo copia hasta param->data_size en el espacio de usuario, por lo que parte del resultado se truncar\u00e1. Corrija este error estableciendo \"iter_info.end = (char *)vers + needed;\" Esto garantiza que la segunda llamada \"dm_target_iterate\" solo escriba hasta el b\u00fafer necesario y finalice con \"DM_BUFFER_FULL_FLAG\" si se desborda dicho espacio. En este caso, el espacio de usuario asignar\u00e1 un b\u00fafer mayor y reintentar\u00e1. Tenga en cuenta que tambi\u00e9n hay un error en list_version_get_needed: debemos agregar \"strlen(tt->name) + 1\" al tama\u00f1o necesario, no \"strlen(tt->name)\"."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49772.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Drop snd_BUG_ON() from snd_usbmidi_output_open()\n\nsnd_usbmidi_output_open() has a check of the NULL port with\nsnd_BUG_ON().  snd_BUG_ON() was used as this shouldn't have happened,\nbut in reality, the NULL port may be seen when the device gives an\ninvalid endpoint setup at the descriptor, hence the driver skips the\nallocation.  That is, the check itself is valid and snd_BUG_ON()\nshould be dropped from there.  Otherwise it's confusing as if it were\na real bug, as recently syzbot stumbled on it."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usb-audio: Se omite snd_BUG_ON() de snd_usbmidi_output_open(). snd_usbmidi_output_open() tiene una comprobaci\u00f3n del puerto nulo con snd_BUG_ON(). Se us\u00f3 snd_BUG_ON() porque esto no deber\u00eda haber ocurrido, pero en realidad, el puerto nulo puede detectarse cuando el dispositivo proporciona una configuraci\u00f3n de endpoint no v\u00e1lida en el descriptor, por lo que el controlador omite la asignaci\u00f3n. Es decir, la comprobaci\u00f3n en s\u00ed es v\u00e1lida y snd_BUG_ON() deber\u00eda omitirse. De lo contrario, es confuso, como si se tratara de un error real, como lo detect\u00f3 syzbot recientemente."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49773.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix optc2_configure warning on dcn314\n\n[Why]\ndcn314 uses optc2_configure_crc() that wraps\noptc1_configure_crc() + set additional registers\nnot applicable to dcn314.\nIt's not critical but when used leads to warning like:\nWARNING: drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c\nCall Trace:\n<TASK>\ngeneric_reg_set_ex+0x6d/0xe0 [amdgpu]\noptc2_configure_crc+0x60/0x80 [amdgpu]\ndc_stream_configure_crc+0x129/0x150 [amdgpu]\namdgpu_dm_crtc_configure_crc_source+0x5d/0xe0 [amdgpu]\n\n[How]\nUse optc1_configure_crc() directly"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Se corrige la advertencia de optc2_configure en dcn314 [Por qu\u00e9] dcn314 usa optc2_configure_crc() que envuelve optc1_configure_crc() + establece registros adicionales que no son aplicables a dcn314. No es cr\u00edtico, pero cuando se usa genera advertencias como: ADVERTENCIA: drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c Seguimiento de llamadas:  generic_reg_set_ex+0x6d/0xe0 [amdgpu] optc2_configure_crc+0x60/0x80 [amdgpu] dc_stream_configure_crc+0x129/0x150 [amdgpu] amdgpu_dm_crtc_configure_crc_source+0x5d/0xe0 [amdgpu] [How] Use optc1_configure_crc() directly "
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49774.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/xen: Fix eventfd error handling in kvm_xen_eventfd_assign()\n\nShould not call eventfd_ctx_put() in case of error.\n\n[Introduce new goto target instead. - Paolo]"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: x86/xen: Se corrige el manejo de errores de eventfd en kvm_xen_eventfd_assign(). No se debe llamar a eventfd_ctx_put() en caso de error. [Introducir un nuevo objetivo goto en su lugar. - Paolo]"
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49775.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: cdg: allow tcp_cdg_release() to be called multiple times\n\nApparently, mptcp is able to call tcp_disconnect() on an already\ndisconnected flow. This is generally fine, unless current congestion\ncontrol is CDG, because it might trigger a double-free [1]\n\nInstead of fixing MPTCP, and future bugs, we can make tcp_disconnect()\nmore resilient.\n\n[1]\nBUG: KASAN: double-free in slab_free mm/slub.c:3539 [inline]\nBUG: KASAN: double-free in kfree+0xe2/0x580 mm/slub.c:4567\n\nCPU: 0 PID: 3645 Comm: kworker/0:7 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022\nWorkqueue: events mptcp_worker\nCall Trace:\n<TASK>\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\nprint_address_description mm/kasan/report.c:317 [inline]\nprint_report.cold+0x2ba/0x719 mm/kasan/report.c:433\nkasan_report_invalid_free+0x81/0x190 mm/kasan/report.c:462\n____kasan_slab_free+0x18b/0x1c0 mm/kasan/common.c:356\nkasan_slab_free include/linux/kasan.h:200 [inline]\nslab_free_hook mm/slub.c:1759 [inline]\nslab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785\nslab_free mm/slub.c:3539 [inline]\nkfree+0xe2/0x580 mm/slub.c:4567\ntcp_disconnect+0x980/0x1e20 net/ipv4/tcp.c:3145\n__mptcp_close_ssk+0x5ca/0x7e0 net/mptcp/protocol.c:2327\nmptcp_do_fastclose net/mptcp/protocol.c:2592 [inline]\nmptcp_worker+0x78c/0xff0 net/mptcp/protocol.c:2627\nprocess_one_work+0x991/0x1610 kernel/workqueue.c:2289\nworker_thread+0x665/0x1080 kernel/workqueue.c:2436\nkthread+0x2e4/0x3a0 kernel/kthread.c:376\nret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n</TASK>\n\nAllocated by task 3671:\nkasan_save_stack+0x1e/0x40 mm/kasan/common.c:38\nkasan_set_track mm/kasan/common.c:45 [inline]\nset_alloc_info mm/kasan/common.c:437 [inline]\n____kasan_kmalloc mm/kasan/common.c:516 [inline]\n____kasan_kmalloc mm/kasan/common.c:475 [inline]\n__kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:525\nkmalloc_array include/linux/slab.h:640 [inline]\nkcalloc include/linux/slab.h:671 [inline]\ntcp_cdg_init+0x10d/0x170 net/ipv4/tcp_cdg.c:380\ntcp_init_congestion_control+0xab/0x550 net/ipv4/tcp_cong.c:193\ntcp_reinit_congestion_control net/ipv4/tcp_cong.c:217 [inline]\ntcp_set_congestion_control+0x96c/0xaa0 net/ipv4/tcp_cong.c:391\ndo_tcp_setsockopt+0x505/0x2320 net/ipv4/tcp.c:3513\ntcp_setsockopt+0xd4/0x100 net/ipv4/tcp.c:3801\nmptcp_setsockopt+0x35f/0x2570 net/mptcp/sockopt.c:844\n__sys_setsockopt+0x2d6/0x690 net/socket.c:2252\n__do_sys_setsockopt net/socket.c:2263 [inline]\n__se_sys_setsockopt net/socket.c:2260 [inline]\n__x64_sys_setsockopt+0xba/0x150 net/socket.c:2260\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nFreed by task 16:\nkasan_save_stack+0x1e/0x40 mm/kasan/common.c:38\nkasan_set_track+0x21/0x30 mm/kasan/common.c:45\nkasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370\n____kasan_slab_free mm/kasan/common.c:367 [inline]\n____kasan_slab_free+0x166/0x1c0 mm/kasan/common.c:329\nkasan_slab_free include/linux/kasan.h:200 [inline]\nslab_free_hook mm/slub.c:1759 [inline]\nslab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785\nslab_free mm/slub.c:3539 [inline]\nkfree+0xe2/0x580 mm/slub.c:4567\ntcp_cleanup_congestion_control+0x70/0x120 net/ipv4/tcp_cong.c:226\ntcp_v4_destroy_sock+0xdd/0x750 net/ipv4/tcp_ipv4.c:2254\ntcp_v6_destroy_sock+0x11/0x20 net/ipv6/tcp_ipv6.c:1969\ninet_csk_destroy_sock+0x196/0x440 net/ipv4/inet_connection_sock.c:1157\ntcp_done+0x23b/0x340 net/ipv4/tcp.c:4649\ntcp_rcv_state_process+0x40e7/0x4990 net/ipv4/tcp_input.c:6624\ntcp_v6_do_rcv+0x3fc/0x13c0 net/ipv6/tcp_ipv6.c:1525\ntcp_v6_rcv+0x2e8e/0x3830 net/ipv6/tcp_ipv6.c:1759\nip6_protocol_deliver_rcu+0x2db/0x1950 net/ipv6/ip6_input.c:439\nip6_input_finish+0x14c/0x2c0 net/ipv6/ip6_input.c:484\nNF_HOOK include/linux/netfilter.h:302 [inline]\nNF_HOOK include/linux/netfilter.h:296 [inline]\nip6_input+0x9c/0xd\n---truncated---"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tcp:cdg: permite llamar a tcp_cdg_release() varias veces. Aparentemente, mptcp puede llamar a tcp_disconnect() en un flujo ya desconectado. Esto generalmente funciona bien, a menos que el control de congesti\u00f3n actual sea CDG, ya que podr\u00eda desencadenar una doble liberaci\u00f3n [1]. En lugar de corregir MPTCP y futuros errores, podemos hacer que tcp_disconnect() sea m\u00e1s resistente. [1] ERROR: KASAN: doble liberaci\u00f3n en slab_free mm/slub.c:3539 [en l\u00ednea] ERROR: KASAN: doble liberaci\u00f3n en kfree+0xe2/0x580 mm/slub.c:4567 CPU: 0 PID: 3645 Comm: kworker/0:7 No contaminado 6.0.0-syzkaller-02734-g0326074ff465 #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 22/09/2022 Cola de trabajo: eventos mptcp_worker Rastreo de llamadas:  __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report_invalid_free+0x81/0x190 mm/kasan/report.c:462 ____kasan_slab_free+0x18b/0x1c0 mm/kasan/common.c:356 kasan_slab_free include/linux/kasan.h:200 [inline] slab_free_hook mm/slub.c:1759 [inline] slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785 slab_free mm/slub.c:3539 [inline] kfree+0xe2/0x580 mm/slub.c:4567 tcp_disconnect+0x980/0x1e20 net/ipv4/tcp.c:3145 __mptcp_close_ssk+0x5ca/0x7e0 net/mptcp/protocol.c:2327 mptcp_do_fastclose net/mptcp/protocol.c:2592 [inline] mptcp_worker+0x78c/0xff0 net/mptcp/protocol.c:2627 process_one_work+0x991/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306  Allocated by task 3671: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline] ____kasan_kmalloc mm/kasan/common.c:516 [inline] ____kasan_kmalloc mm/kasan/common.c:475 [inline] __kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:525 kmalloc_array include/linux/slab.h:640 [inline] kcalloc include/linux/slab.h:671 [inline] tcp_cdg_init+0x10d/0x170 net/ipv4/tcp_cdg.c:380 tcp_init_congestion_control+0xab/0x550 net/ipv4/tcp_cong.c:193 tcp_reinit_congestion_control net/ipv4/tcp_cong.c:217 [inline] tcp_set_congestion_control+0x96c/0xaa0 net/ipv4/tcp_cong.c:391 do_tcp_setsockopt+0x505/0x2320 net/ipv4/tcp.c:3513 tcp_setsockopt+0xd4/0x100 net/ipv4/tcp.c:3801 mptcp_setsockopt+0x35f/0x2570 net/mptcp/sockopt.c:844 __sys_setsockopt+0x2d6/0x690 net/socket.c:2252 __do_sys_setsockopt net/socket.c:2263 [inline] __se_sys_setsockopt net/socket.c:2260 [inline] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2260 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 16: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track+0x21/0x30 mm/kasan/common.c:45 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370 ____kasan_slab_free mm/kasan/common.c:367 [inline] ____kasan_slab_free+0x166/0x1c0 mm/kasan/common.c:329 kasan_slab_free include/linux/kasan.h:200 [inline] slab_free_hook mm/slub.c:1759 [inline] slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785 slab_free mm/slub.c:3539 [inline] kfree+0xe2/0x580 mm/slub.c:4567 tcp_cleanup_congestion_control+0x70/0x120 net/ipv4/tcp_cong.c:226 tcp_v4_destroy_sock+0xdd/0x750 net/ipv4/tcp_ipv4.c:2254 tcp_v6_destroy_sock+0x11/0x20 net/ipv6/tcp_ipv6.c:1969 inet_csk_destroy_sock+0x196/0x440 net/ipv4/inet_connection_sock.c:1157 tcp_done+0x23b/0x340 net/ipv4/tcp.c:4649 tcp_rcv_state_process+0x40e7/0x4990 net/ipv4/tcp_input.c:6624 tcp_v6_do_rcv+0x3fc/0x13c0 net/ipv6/tcp_ipv6.c:1525 tcp_v6_rcv+0x2e8e/0x3830 net/ipv6/tcp_ipv6.c:1759 ip6_protocol_deliver_rcu+0x2db/0x1950 net/ipv6/ip6_input.c:439 ip6_input_finish+0x14c/0x2c0 net/ipv6/ip6_input.c:484 NF_HOOK include/linux/netfilter.h:302 [inline] NF_HOOK include/linux/netfilter.h:296 [inline] ip6_input+0x9c/0xd ---truncado---"
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49776.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmacvlan: enforce a consistent minimal mtu\n\nmacvlan should enforce a minimal mtu of 68, even at link creation.\n\nThis patch avoids the current behavior (which could lead to crashes\nin ipv6 stack if the link is brought up)\n\n$ ip link add macvlan1 link eno1 mtu 8 type macvlan  # This should fail !\n$ ip link sh dev macvlan1\n5: macvlan1@eno1: <BROADCAST,MULTICAST> mtu 8 qdisc noop\n    state DOWN mode DEFAULT group default qlen 1000\n    link/ether 02:47:6c:24:74:82 brd ff:ff:ff:ff:ff:ff\n$ ip link set macvlan1 mtu 67\nError: mtu less than device minimum.\n$ ip link set macvlan1 mtu 68\n$ ip link set macvlan1 mtu 8\nError: mtu less than device minimum."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: macvlan: exige una MTU m\u00ednima consistente. macvlan deber\u00eda exigir una MTU m\u00ednima de 68, incluso al crear el enlace. Este parche evita el comportamiento actual (que podr\u00eda provocar fallos en la pila IPv6 si se activa el enlace). $ ip link add macvlan1 link eno1 mtu 8 type macvlan # \u00a1Esto deber\u00eda fallar! $ ip link sh dev macvlan1 5: macvlan1@eno1:  mtu 8 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 02:47:6c:24:74:82 brd ff:ff:ff:ff:ff:ff $ ip link set macvlan1 mtu 67 Error: MTU menor que el m\u00ednimo del dispositivo. $ ip link set macvlan1 mtu 68 $ ip link set macvlan1 mtu 8 Error: mtu menor que el m\u00ednimo del dispositivo."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49777.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nInput: i8042 - fix leaking of platform device on module removal\n\nAvoid resetting the module-wide i8042_platform_device pointer in\ni8042_probe() or i8042_remove(), so that the device can be properly\ndestroyed by i8042_exit() on module unload."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: i8042 - reparar fuga del dispositivo de plataforma al quitar un m\u00f3dulo Evite restablecer el puntero i8042_platform_device de todo el m\u00f3dulo en i8042_probe() o i8042_remove(), de modo que el dispositivo pueda ser destruido correctamente por i8042_exit() al descargar el m\u00f3dulo."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49778.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64/mm: fix incorrect file_map_count for non-leaf pmd/pud\n\nThe page table check trigger BUG_ON() unexpectedly when collapse hugepage:\n\n ------------[ cut here ]------------\n kernel BUG at mm/page_table_check.c:82!\n Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n Dumping ftrace buffer:\n    (ftrace buffer empty)\n Modules linked in:\n CPU: 6 PID: 68 Comm: khugepaged Not tainted 6.1.0-rc3+ #750\n Hardware name: linux,dummy-virt (DT)\n pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : page_table_check_clear.isra.0+0x258/0x3f0\n lr : page_table_check_clear.isra.0+0x240/0x3f0\n[...]\n Call trace:\n  page_table_check_clear.isra.0+0x258/0x3f0\n  __page_table_check_pmd_clear+0xbc/0x108\n  pmdp_collapse_flush+0xb0/0x160\n  collapse_huge_page+0xa08/0x1080\n  hpage_collapse_scan_pmd+0xf30/0x1590\n  khugepaged_scan_mm_slot.constprop.0+0x52c/0xac8\n  khugepaged+0x338/0x518\n  kthread+0x278/0x2f8\n  ret_from_fork+0x10/0x20\n[...]\n\nSince pmd_user_accessible_page() doesn't check if a pmd is leaf, it\ndecrease file_map_count for a non-leaf pmd comes from collapse_huge_page().\nand so trigger BUG_ON() unexpectedly.\n\nFix this problem by using pmd_leaf() insteal of pmd_present() in\npmd_user_accessible_page(). Moreover, use pud_leaf() for\npud_user_accessible_page() too."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64/mm: corrige el file_map_count incorrecto para pmd/pud que no es de hoja. La comprobaci\u00f3n de la tabla de p\u00e1ginas se activa inesperadamente BUG_ON() cuando se colapsa hugepage: ------------[ cortar aqu\u00ed ]------------ \u00a1ERROR del kernel en mm/page_table_check.c:82! Error interno: Ups - BUG: 00000000f2000800 [#1] SMP Volcando b\u00fafer ftrace: (b\u00fafer ftrace vac\u00edo) M\u00f3dulos enlazados: CPU: 6 PID: 68 Comm: khugepaged No contaminado 6.1.0-rc3+ #750 Nombre del hardware: linux,dummy-virt (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : page_table_check_clear.isra.0+0x258/0x3f0 lr : page_table_check_clear.isra.0+0x240/0x3f0 [...] Rastreo de llamadas: page_table_check_clear.isra.0+0x258/0x3f0 __page_table_check_pmd_clear+0xbc/0x108 pmdp_collapse_flush+0xb0/0x160 collapse_huge_page+0xa08/0x1080 hpage_collapse_scan_pmd+0xf30/0x1590 khugepaged_scan_mm_slot.constprop.0+0x52c/0xac8 khugepaged+0x338/0x518 kthread+0x278/0x2f8 ret_from_fork+0x10/0x20 [...] Dado que pmd_user_accessible_page() no comprueba si un pmd es hoja, disminuye file_map_count para un pmd que no es hoja que proviene de colapso_huge_page() y, por lo tanto, activa BUG_ON() inesperadamente. Solucione este problema usando pmd_leaf() en lugar de pmd_present() en pmd_user_accessible_page(). Adem\u00e1s, use pud_leaf() para pud_user_accessible_page()."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49779.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nkprobes: Skip clearing aggrprobe's post_handler in kprobe-on-ftrace case\n\nIn __unregister_kprobe_top(), if the currently unregistered probe has\npost_handler but other child probes of the aggrprobe do not have\npost_handler, the post_handler of the aggrprobe is cleared. If this is\na ftrace-based probe, there is a problem. In later calls to\ndisarm_kprobe(), we will use kprobe_ftrace_ops because post_handler is\nNULL. But we're armed with kprobe_ipmodify_ops. This triggers a WARN in\n__disarm_kprobe_ftrace() and may even cause use-after-free:\n\n  Failed to disarm kprobe-ftrace at kernel_clone+0x0/0x3c0 (error -2)\n  WARNING: CPU: 5 PID: 137 at kernel/kprobes.c:1135 __disarm_kprobe_ftrace.isra.21+0xcf/0xe0\n  Modules linked in: testKprobe_007(-)\n  CPU: 5 PID: 137 Comm: rmmod Not tainted 6.1.0-rc4-dirty #18\n  [...]\n  Call Trace:\n   <TASK>\n   __disable_kprobe+0xcd/0xe0\n   __unregister_kprobe_top+0x12/0x150\n   ? mutex_lock+0xe/0x30\n   unregister_kprobes.part.23+0x31/0xa0\n   unregister_kprobe+0x32/0x40\n   __x64_sys_delete_module+0x15e/0x260\n   ? do_user_addr_fault+0x2cd/0x6b0\n   do_syscall_64+0x3a/0x90\n   entry_SYSCALL_64_after_hwframe+0x63/0xcd\n   [...]\n\nFor the kprobe-on-ftrace case, we keep the post_handler setting to\nidentify this aggrprobe armed with kprobe_ipmodify_ops. This way we\ncan disarm it correctly."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kprobes: Omitir la limpieza del post_handler de aggrprobe en el caso de kprobe-on-ftrace. En __unregister_kprobe_top(), si la sonda actualmente no registrada tiene post_handler, pero otras sondas secundarias de aggrprobe no lo tienen, se limpia el post_handler de aggrprobe. Si se trata de una sonda basada en ftrace, existe un problema. En llamadas posteriores a disarm_kprobe(), usaremos kprobe_ftrace_ops porque post_handler es NULL. Pero estamos preparados con kprobe_ipmodify_ops. Esto activa una ADVERTENCIA en __disarm_kprobe_ftrace() e incluso puede provocar un use-after-free: No se pudo desarmar kprobe-ftrace en kernel_clone+0x0/0x3c0 (error -2) ADVERTENCIA: CPU: 5 PID: 137 en kernel/kprobes.c:1135 __disarm_kprobe_ftrace.isra.21+0xcf/0xe0 M\u00f3dulos vinculados en: testKprobe_007(-) CPU: 5 PID: 137 Comm: rmmod No contaminado 6.1.0-rc4-dirty #18 [...] Seguimiento de llamadas:  __disable_kprobe+0xcd/0xe0 __unregister_kprobe_top+0x12/0x150 ? mutex_lock+0xe/0x30 unregister_kprobes.part.23+0x31/0xa0 unregister_kprobe+0x32/0x40 __x64_sys_delete_module+0x15e/0x260 ? do_user_addr_fault+0x2cd/0x6b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] For the kprobe-on-ftrace case, we keep the post_handler setting to identify this aggrprobe armed with kprobe_ipmodify_ops. De esta forma, podemos desactivarla correctamente."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49780.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus()\n\nIf device_register() fails in tcm_loop_setup_hba_bus(), the name allocated\nby dev_set_name() need be freed. As comment of device_register() says, it\nshould use put_device() to give up the reference in the error path. So fix\nthis by calling put_device(), then the name can be freed in kobject_cleanup().\nThe 'tl_hba' will be freed in tcm_loop_release_adapter(), so it don't need\ngoto error label in this case."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: target: tcm_loop: Se corrige una posible fuga de nombre en tcm_loop_setup_hba_bus(). Si device_register() falla en tcm_loop_setup_hba_bus(), se debe liberar el nombre asignado por dev_set_name(). Como se indica en el comentario de device_register(), se debe usar put_device() para liberar la referencia en la ruta de error. Para solucionar esto, se debe llamar a put_device(); luego, el nombre se puede liberar en kobject_cleanup(). El 'tl_hba' se liberar\u00e1 en tcm_loop_release_adapter(), por lo que no es necesario ir a la etiqueta de error en este caso."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49781.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/amd: Fix crash due to race between amd_pmu_enable_all, perf NMI and throttling\n\namd_pmu_enable_all() does:\n\n      if (!test_bit(idx, cpuc->active_mask))\n              continue;\n\n      amd_pmu_enable_event(cpuc->events[idx]);\n\nA perf NMI of another event can come between these two steps. Perf NMI\nhandler internally disables and enables _all_ events, including the one\nwhich nmi-intercepted amd_pmu_enable_all() was in process of enabling.\nIf that unintentionally enabled event has very low sampling period and\ncauses immediate successive NMI, causing the event to be throttled,\ncpuc->events[idx] and cpuc->active_mask gets cleared by x86_pmu_stop().\nThis will result in amd_pmu_enable_event() getting called with event=NULL\nwhen amd_pmu_enable_all() resumes after handling the NMIs. This causes a\nkernel crash:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000198\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  [...]\n  Call Trace:\n   <TASK>\n   amd_pmu_enable_all+0x68/0xb0\n   ctx_resched+0xd9/0x150\n   event_function+0xb8/0x130\n   ? hrtimer_start_range_ns+0x141/0x4a0\n   ? perf_duration_warn+0x30/0x30\n   remote_function+0x4d/0x60\n   __flush_smp_call_function_queue+0xc4/0x500\n   flush_smp_call_function_queue+0x11d/0x1b0\n   do_idle+0x18f/0x2d0\n   cpu_startup_entry+0x19/0x20\n   start_secondary+0x121/0x160\n   secondary_startup_64_no_verify+0xe5/0xeb\n   </TASK>\n\namd_pmu_disable_all()/amd_pmu_enable_all() calls inside perf NMI handler\nwere recently added as part of BRS enablement but I'm not sure whether\nwe really need them. We can just disable BRS in the beginning and enable\nit back while returning from NMI. This will solve the issue by not\nenabling those events whose active_masks are set but are not yet enabled\nin hw pmu."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/x86/amd: Se corrige el fallo debido a la competencia entre amd_pmu_enable_all, perf NMI y la limitaci\u00f3n. amd_pmu_enable_all() realiza lo siguiente: if (!test_bit(idx, cpuc-&gt;active_mask)) continue; amd_pmu_enable_event(cpuc-&gt;events[idx]); Un perf NMI de otro evento puede interponerse entre estos dos pasos. El controlador de perf NMI deshabilita y habilita internamente _todos_ los eventos, incluido el que amd_pmu_enable_all() interceptado por nmi estaba habilitando. Si ese evento habilitado involuntariamente tiene un per\u00edodo de muestreo muy bajo y causa NMI sucesivas inmediatas, lo que provoca su limitaci\u00f3n, x86_pmu_stop() borra cpuc-&gt;events[idx] y cpuc-&gt;active_mask. Esto provocar\u00e1 que amd_pmu_enable_event() se llame con event=NULL cuando amd_pmu_enable_all() se reanude tras gestionar las NMI. Esto provoca un fallo del kernel: BUG: kernel NULL pointer dereference, address: 0000000000000198 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - not-present page [...] Rastreo de llamadas:   amd_pmu_enable_all+0x68/0xb0 ctx_resched+0xd9/0x150 event_function+0xb8/0x130 ? hrtimer_start_range_ns+0x141/0x4a0 ? perf_duration_warn+0x30/0x30 remote_function+0x4d/0x60 __flush_smp_call_function_queue+0xc4/0x500 flush_smp_call_function_queue+0x11d/0x1b0 do_idle+0x18f/0x2d0 cpu_startup_entry+0x19/0x20 start_secondary+0x121/0x160 secondary_startup_64_no_verify+0xe5/0xeb  amd_pmu_disable_all()/amd_pmu_enable_all() Las llamadas dentro del controlador NMI de rendimiento se a\u00f1adieron recientemente como parte de la habilitaci\u00f3n de BRS, pero no estoy seguro de si realmente las necesitamos. Podemos deshabilitar BRS al principio y volver a habilitarlo al regresar de NMI. Esto solucionar\u00e1 el problema al no habilitar los eventos cuyas m\u00e1scaras activas est\u00e9n configuradas, pero que a\u00fan no est\u00e9n habilitadas en la PMU de hardware."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49782.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf: Improve missing SIGTRAP checking\n\nTo catch missing SIGTRAP we employ a WARN in __perf_event_overflow(),\nwhich fires if pending_sigtrap was already set: returning to user space\nwithout consuming pending_sigtrap, and then having the event fire again\nwould re-enter the kernel and trigger the WARN.\n\nThis, however, seemed to miss the case where some events not associated\nwith progress in the user space task can fire and the interrupt handler\nruns before the IRQ work meant to consume pending_sigtrap (and generate\nthe SIGTRAP).\n\nsyzbot gifted us this stack trace:\n\n | WARNING: CPU: 0 PID: 3607 at kernel/events/core.c:9313 __perf_event_overflow\n | Modules linked in:\n | CPU: 0 PID: 3607 Comm: syz-executor100 Not tainted 6.1.0-rc2-syzkaller-00073-g88619e77b33d #0\n | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022\n | RIP: 0010:__perf_event_overflow+0x498/0x540 kernel/events/core.c:9313\n | <...>\n | Call Trace:\n |  <TASK>\n |  perf_swevent_hrtimer+0x34f/0x3c0 kernel/events/core.c:10729\n |  __run_hrtimer kernel/time/hrtimer.c:1685 [inline]\n |  __hrtimer_run_queues+0x1c6/0xfb0 kernel/time/hrtimer.c:1749\n |  hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811\n |  local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1096 [inline]\n |  __sysvec_apic_timer_interrupt+0x17c/0x640 arch/x86/kernel/apic/apic.c:1113\n |  sysvec_apic_timer_interrupt+0x40/0xc0 arch/x86/kernel/apic/apic.c:1107\n |  asm_sysvec_apic_timer_interrupt+0x16/0x20 arch/x86/include/asm/idtentry.h:649\n | <...>\n |  </TASK>\n\nIn this case, syzbot produced a program with event type\nPERF_TYPE_SOFTWARE and config PERF_COUNT_SW_CPU_CLOCK. The hrtimer\nmanages to fire again before the IRQ work got a chance to run, all while\nnever having returned to user space.\n\nImprove the WARN to check for real progress in user space: approximate\nthis by storing a 32-bit hash of the current IP into pending_sigtrap,\nand if an event fires while pending_sigtrap still matches the previous\nIP, we assume no progress (false negatives are possible given we could\nreturn to user space and trigger again on the same IP)."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf: Mejora de la comprobaci\u00f3n de SIGTRAP faltantes. Para detectar la falta de SIGTRAP, empleamos una advertencia en __perf_event_overflow(), que se activa si pending_sigtrap ya estaba configurado: al regresar al espacio de usuario sin consumir pending_sigtrap y luego volver a activar el evento, se reingresar\u00eda al kernel y se activar\u00eda la advertencia. Sin embargo, esto parec\u00eda pasar por alto el caso en el que algunos eventos no asociados con el progreso en la tarea del espacio de usuario pueden activarse y el controlador de interrupciones se ejecuta antes del trabajo de IRQ destinado a consumir pending_sigtrap (y generar la SIGTRAP). syzbot nos proporcion\u00f3 este seguimiento de pila: | ADVERTENCIA: CPU: 0 PID: 3607 en kernel/events/core.c:9313 __perf_event_overflow | M\u00f3dulos enlazados en: | CPU: 0 PID: 3607 Comm: syz-executor100 No contaminado 6.1.0-rc2-syzkaller-00073-g88619e77b33d #0 | Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 | RIP: 0010:__perf_event_overflow+0x498/0x540 kernel/events/core.c:9313 | &lt;...&gt; | Seguimiento de llamadas: |  | perf_swevent_hrtimer+0x34f/0x3c0 kernel/events/core.c:10729 | __run_hrtimer kernel/time/hrtimer.c:1685 [inline] | __hrtimer_run_queues+0x1c6/0xfb0 kernel/time/hrtimer.c:1749 | hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811 | local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1096 [inline] | __sysvec_apic_timer_interrupt+0x17c/0x640 arch/x86/kernel/apic/apic.c:1113 | sysvec_apic_timer_interrupt+0x40/0xc0 arch/x86/kernel/apic/apic.c:1107 | asm_sysvec_apic_timer_interrupt+0x16/0x20 arch/x86/include/asm/idtentry.h:649 | &lt;...&gt; |  En este caso, syzbot gener\u00f3 un programa con el tipo de evento PERF_TYPE_SOFTWARE y la configuraci\u00f3n PERF_COUNT_SW_CPU_CLOCK. El temporizador hrtimer se vuelve a ejecutar antes de que el trabajo de IRQ tenga la oportunidad de ejecutarse, sin haber regresado al espacio de usuario. Mejore el WARN para comprobar el progreso real en el espacio de usuario: aproxime esto almacenando un hash de 32 bits de la IP actual en pending_sigtrap. Si un evento se dispara mientras pending_sigtrap a\u00fan coincide con la IP anterior, asumimos que no hay progreso (los falsos negativos son posibles dado que podr\u00edamos regresar al espacio de usuario y disparar de nuevo en la misma IP)."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49783.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Drop fpregs lock before inheriting FPU permissions\n\nMike Galbraith reported the following against an old fork of preempt-rt\nbut the same issue also applies to the current preempt-rt tree.\n\n   BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46\n   in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd\n   preempt_count: 1, expected: 0\n   RCU nest depth: 0, expected: 0\n   Preemption disabled at:\n   fpu_clone\n   CPU: 6 PID: 1 Comm: systemd Tainted: G            E       (unreleased)\n   Call Trace:\n    <TASK>\n    dump_stack_lvl\n    ? fpu_clone\n    __might_resched\n    rt_spin_lock\n    fpu_clone\n    ? copy_thread\n    ? copy_process\n    ? shmem_alloc_inode\n    ? kmem_cache_alloc\n    ? kernel_clone\n    ? __do_sys_clone\n    ? do_syscall_64\n    ? __x64_sys_rt_sigprocmask\n    ? syscall_exit_to_user_mode\n    ? do_syscall_64\n    ? syscall_exit_to_user_mode\n    ? do_syscall_64\n    ? syscall_exit_to_user_mode\n    ? do_syscall_64\n    ? exc_page_fault\n    ? entry_SYSCALL_64_after_hwframe\n    </TASK>\n\nMike says:\n\n  The splat comes from fpu_inherit_perms() being called under fpregs_lock(),\n  and us reaching the spin_lock_irq() therein due to fpu_state_size_dynamic()\n  returning true despite static key __fpu_state_size_dynamic having never\n  been enabled.\n\nMike's assessment looks correct. fpregs_lock on a PREEMPT_RT kernel disables\npreemption so calling spin_lock_irq() in fpu_inherit_perms() is unsafe. This\nproblem exists since commit\n\n  9e798e9aa14c (\"x86/fpu: Prepare fpu_clone() for dynamically enabled features\").\n\nEven though the original bug report should not have enabled the paths at\nall, the bug still exists.\n\nfpregs_lock is necessary when editing the FPU registers or a task's FP\nstate but it is not necessary for fpu_inherit_perms(). The only write\nof any FP state in fpu_inherit_perms() is for the new child which is\nnot running yet and cannot context switch or be borrowed by a kernel\nthread yet. Hence, fpregs_lock is not protecting anything in the new\nchild until clone() completes and can be dropped earlier. The siglock\nstill needs to be acquired by fpu_inherit_perms() as the read of the\nparent's permissions has to be serialised.\n\n  [ bp: Cleanup splat. ]"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/fpu: Eliminar el bloqueo de fpregs antes de heredar los permisos de FPU Mike Galbraith inform\u00f3 lo siguiente contra una antigua bifurcaci\u00f3n de preempt-rt, pero el mismo problema tambi\u00e9n se aplica al \u00e1rbol preempt-rt actual. ERROR: funci\u00f3n inactiva llamada desde un contexto no v\u00e1lido en kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd preempt_count: 1, expected: 0 Profundidad de anidamiento de RCU: 0, expected: 0 Preempci\u00f3n deshabilitada en: fpu_clone CPU: 6 PID: 1 Comm: systemd Tainted: GE (no publicado) Rastreo de llamadas:   dump_stack_lvl ? fpu_clone __might_resched rt_spin_lock fpu_clone ? copy_thread ? copy_process ? shmem_alloc_inode ? kmem_cache_alloc ? kernel_clone ? __do_sys_clone ? do_syscall_64 ? __x64_sys_rt_sigprocmask ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? exc_page_fault ? entry_SYSCALL_64_after_hwframe   Mike dice: El problema se debe a que fpu_inherit_perms() se llama bajo fpregs_lock() y a que alcanzamos spin_lock_irq() debido a que fpu_state_size_dynamic() devuelve verdadero a pesar de que la clave est\u00e1tica __fpu_state_size_dynamic nunca se ha habilitado. La evaluaci\u00f3n de Mike parece correcta. fpregs_lock en un kernel PREEMPT_RT deshabilita la preempci\u00f3n, por lo que llamar a spin_lock_irq() en fpu_inherit_perms() no es seguro. Este problema existe desde la confirmaci\u00f3n 9e798e9aa14c (\"x86/fpu: Preparar fpu_clone() para funciones habilitadas din\u00e1micamente\"). Aunque el informe de error original no deber\u00eda haber habilitado las rutas, el error persiste. fpregs_lock es necesario al editar los registros de FPU o el estado de FP de una tarea, pero no es necesario para fpu_inherit_perms(). La \u00fanica escritura de cualquier estado de FP en fpu_inherit_perms() es para el nuevo hijo, que a\u00fan no se est\u00e1 ejecutando y a\u00fan no puede cambiar de contexto ni ser tomado prestado por un hilo del kernel. Por lo tanto, fpregs_lock no protege nada en el nuevo hijo hasta que clone() se complete y pueda eliminarse antes. El siglock a\u00fan debe ser adquirido por fpu_inherit_perms(), ya que la lectura de los permisos del padre debe serializarse. [bp: Limpieza splat.]"
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49784.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/amd/uncore: Fix memory leak for events array\n\nWhen a CPU comes online, the per-CPU NB and LLC uncore contexts are\nfreed but not the events array within the context structure. This\ncauses a memory leak as identified by the kmemleak detector.\n\n  [...]\n  unreferenced object 0xffff8c5944b8e320 (size 32):\n    comm \"swapper/0\", pid 1, jiffies 4294670387 (age 151.072s)\n    hex dump (first 32 bytes):\n      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    backtrace:\n      [<000000000759fb79>] amd_uncore_cpu_up_prepare+0xaf/0x230\n      [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470\n      [<0000000093e727d4>] cpuhp_issue_call+0x14d/0x170\n      [<0000000045464d54>] __cpuhp_setup_state_cpuslocked+0x11e/0x330\n      [<0000000069f67cbd>] __cpuhp_setup_state+0x6b/0x110\n      [<0000000015365e0f>] amd_uncore_init+0x260/0x321\n      [<00000000089152d2>] do_one_initcall+0x3f/0x1f0\n      [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212\n      [<0000000030be8dde>] kernel_init+0x11/0x120\n      [<0000000059709e59>] ret_from_fork+0x22/0x30\n  unreferenced object 0xffff8c5944b8dd40 (size 64):\n    comm \"swapper/0\", pid 1, jiffies 4294670387 (age 151.072s)\n    hex dump (first 32 bytes):\n      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    backtrace:\n      [<00000000306efe8b>] amd_uncore_cpu_up_prepare+0x183/0x230\n      [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470\n      [<0000000093e727d4>] cpuhp_issue_call+0x14d/0x170\n      [<0000000045464d54>] __cpuhp_setup_state_cpuslocked+0x11e/0x330\n      [<0000000069f67cbd>] __cpuhp_setup_state+0x6b/0x110\n      [<0000000015365e0f>] amd_uncore_init+0x260/0x321\n      [<00000000089152d2>] do_one_initcall+0x3f/0x1f0\n      [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212\n      [<0000000030be8dde>] kernel_init+0x11/0x120\n      [<0000000059709e59>] ret_from_fork+0x22/0x30\n  [...]\n\nFix the problem by freeing the events array before freeing the uncore\ncontext."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/x86/amd/uncore: Se corrige una fuga de memoria en la matriz de eventos. Cuando una CPU se conecta, se liberan los contextos de n\u00facleo \u00fanico (NB) y LLC por CPU, pero no la matriz de eventos dentro de la estructura del contexto. Esto provoca una fuga de memoria, identificada por el detector kmemleak. [...] objeto sin referencia 0xffff8c5944b8e320 (tama\u00f1o 32): comm \"swapper/0\", pid 1, jiffies 4294670387 (edad 151.072s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [&lt;000000000759fb79&gt;] amd_uncore_cpu_up_prepare+0xaf/0x230 [&lt;00000000ddc9e126&gt;] cpuhp_invoke_callback+0x2cf/0x470 [&lt;0000000093e727d4&gt;] cpuhp_issue_call+0x14d/0x170 [&lt;0000000045464d54&gt;] __cpuhp_setup_state_cpuslocked+0x11e/0x330 [&lt;0000000069f67cbd&gt;] __cpuhp_setup_state+0x6b/0x110 [&lt;0000000015365e0f&gt;] amd_uncore_init+0x260/0x321 [&lt;00000000089152d2&gt;] do_one_initcall+0x3f/0x1f0 [&lt;000000002d0bd18d&gt;] kernel_init_freeable+0x1ca/0x212 [&lt;0000000030be8dde&gt;] kernel_init+0x11/0x120 [&lt;0000000059709e59&gt;] ret_from_fork+0x22/0x30 objeto sin referencia 0xffff8c5944b8dd40 (tama\u00f1o 64): comm \"swapper/0\", pid 1, jiffies 4294670387 (edad 151.072s) volcado hexadecimal (primeros 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ seguimiento inverso: [&lt;00000000306efe8b&gt;] preparaci\u00f3n de CPU activada de AMD sin n\u00facleo + 0x183/0x230 [&lt;00000000ddc9e126&gt;] devoluci\u00f3n de llamada de invocaci\u00f3n de CPUHp + 0x2cf/0x470 [&lt;0000000093e727d4&gt;] llamada de emisi\u00f3n de CPUHp + 0x14d/0x170 [&lt;0000000045464d54&gt;] estado de configuraci\u00f3n de CPUHp bloqueado + 0x11e/0x330 [&lt;0000000069f67cbd&gt;] __cpuhp_setup_state+0x6b/0x110 [&lt;0000000015365e0f&gt;] amd_uncore_init+0x260/0x321 [&lt;00000000089152d2&gt;] do_one_initcall+0x3f/0x1f0 [&lt;000000002d0bd18d&gt;] kernel_init_freeable+0x1ca/0x212 [&lt;0000000030be8dde&gt;] kernel_init+0x11/0x120 [&lt;0000000059709e59&gt;] ret_from_fork+0x22/0x30 [...] Solucione el problema liberando la matriz de eventos antes de liberar el contexto uncore."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49785.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/sgx: Add overflow check in sgx_validate_offset_length()\n\nsgx_validate_offset_length() function verifies \"offset\" and \"length\"\narguments provided by userspace, but was missing an overflow check on\ntheir addition. Add it."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/sgx: Se ha a\u00f1adido una comprobaci\u00f3n de desbordamiento en sgx_validate_offset_length(). La funci\u00f3n sgx_validate_offset_length() verifica los argumentos \"offset\" y \"length\" proporcionados por el espacio de usuario, pero no inclu\u00eda una comprobaci\u00f3n de desbordamiento al a\u00f1adirlos. A\u00f1\u00e1dala."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49786.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: properly pin the parent in blkcg_css_online\n\nblkcg_css_online is supposed to pin the blkcg of the parent, but\n397c9f46ee4d refactored things and along the way, changed it to pin the\ncss instead.  This results in extra pins, and we end up leaking blkcgs\nand cgroups."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-cgroup: fija correctamente el padre en blkcg_css_online. Se supone que blkcg_css_online fija el blkcg del padre, pero 397c9f46ee4d refactoriz\u00f3 las cosas y, de paso, lo modific\u00f3 para fijar el CSS. Esto genera fijaciones adicionales y terminamos filtrando blkcgs y cgroups."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49787.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put()\n\npci_get_device() will increase the reference count for the returned\npci_dev. We need to use pci_dev_put() to decrease the reference count\nbefore amd_probe() returns. There is no problem for the 'smbus_dev ==\nNULL' branch because pci_dev_put() can also handle the NULL input\nparameter case."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: sdhci-pci: Se corrige una posible fuga de memoria causada por la omisi\u00f3n de pci_dev_put(). pci_get_device() aumentar\u00e1 el recuento de referencias para el pci_dev devuelto. Necesitamos usar pci_dev_put() para disminuir el recuento de referencias antes de que amd_probe() regrese. No hay problema para la rama 'smbus_dev == NULL', ya que pci_dev_put() tambi\u00e9n puede gestionar el caso del par\u00e1metro de entrada NULL."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49788.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmisc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram()\n\n`struct vmci_event_qp` allocated by qp_notify_peer() contains padding,\nwhich may carry uninitialized data to the userspace, as observed by\nKMSAN:\n\n  BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121\n   instrument_copy_to_user ./include/linux/instrumented.h:121\n   _copy_to_user+0x5f/0xb0 lib/usercopy.c:33\n   copy_to_user ./include/linux/uaccess.h:169\n   vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431\n   vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925\n   vfs_ioctl fs/ioctl.c:51\n  ...\n\n  Uninit was stored to memory at:\n   kmemdup+0x74/0xb0 mm/util.c:131\n   dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271\n   vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339\n   qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479\n   qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662\n   qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750\n   vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940\n   vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488\n   vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927\n  ...\n\n  Local variable ev created at:\n   qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456\n   qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662\n   qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750\n\n  Bytes 28-31 of 48 are uninitialized\n  Memory access of size 48 starts at ffff888035155e00\n  Data copied to user address 0000000020000100\n\nUse memset() to prevent the infoleaks.\n\nAlso speculatively fix qp_notify_peer_local(), which may suffer from the\nsame problem."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: misc/vmw_vmci: se corrige una fuga de informaci\u00f3n en vmci_host_do_receive_datagram() `struct vmci_event_qp` asignado por qp_notify_peer() que contiene relleno, que puede llevar datos no inicializados al espacio de usuario, como lo observ\u00f3 KMSAN: ERROR: KMSAN: fuga de informaci\u00f3n del kernel en instrument_copy_to_user ./include/linux/instrumented.h:121 instrument_copy_to_user ./include/linux/instrumented.h:121 _copy_to_user+0x5f/0xb0 lib/usercopy.c:33 copy_to_user ./include/linux/uaccess.h:169 vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431 vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925 vfs_ioctl fs/ioctl.c:51 ... Uninit se almacen\u00f3 en la memoria en: kmemdup+0x74/0xb0 mm/util.c:131 dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271 vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339 qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479 qp_broker_attach controladores/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 controladores/misc/vmw_vmci/vmci_queue_pair.c:1750 vmci_qp_broker_alloc+0x96/0xd0 controladores/misc/vmw_vmci/vmci_queue_pair.c:1940 vmci_host_do_alloc_queuepair controladores/misc/vmw_vmci/vmci_host.c:488 vmci_host_unlocked_ioctl+0x24fd/0x43d0 controladores/misc/vmw_vmci/vmci_host.c:927 ... Variable local ev creada en: qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 Bytes 28-31 de 48 sin inicializar. El acceso a memoria de tama\u00f1o 48 comienza en ffff888035155e00. Datos copiados a la direcci\u00f3n de usuario 0000000020000100. Use memset() para evitar las filtraciones de informaci\u00f3n. Tambi\u00e9n se especula que se debe corregir qp_notify_peer_local(), que podr\u00eda presentar el mismo problema."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49789.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: zfcp: Fix double free of FSF request when qdio send fails\n\nWe used to use the wrong type of integer in 'zfcp_fsf_req_send()' to cache\nthe FSF request ID when sending a new FSF request. This is used in case the\nsending fails and we need to remove the request from our internal hash\ntable again (so we don't keep an invalid reference and use it when we free\nthe request again).\n\nIn 'zfcp_fsf_req_send()' we used to cache the ID as 'int' (signed and 32\nbit wide), but the rest of the zfcp code (and the firmware specification)\nhandles the ID as 'unsigned long'/'u64' (unsigned and 64 bit wide [s390x\nELF ABI]).  For one this has the obvious problem that when the ID grows\npast 32 bit (this can happen reasonably fast) it is truncated to 32 bit\nwhen storing it in the cache variable and so doesn't match the original ID\nanymore.  The second less obvious problem is that even when the original ID\nhas not yet grown past 32 bit, as soon as the 32nd bit is set in the\noriginal ID (0x80000000 = 2'147'483'648) we will have a mismatch when we\ncast it back to 'unsigned long'. As the cached variable is of a signed\ntype, the compiler will choose a sign-extending instruction to load the 32\nbit variable into a 64 bit register (e.g.: 'lgf %r11,188(%r15)'). So once\nwe pass the cached variable into 'zfcp_reqlist_find_rm()' to remove the\nrequest again all the leading zeros will be flipped to ones to extend the\nsign and won't match the original ID anymore (this has been observed in\npractice).\n\nIf we can't successfully remove the request from the hash table again after\n'zfcp_qdio_send()' fails (this happens regularly when zfcp cannot notify\nthe adapter about new work because the adapter is already gone during\ne.g. a ChpID toggle) we will end up with a double free.  We unconditionally\nfree the request in the calling function when 'zfcp_fsf_req_send()' fails,\nbut because the request is still in the hash table we end up with a stale\nmemory reference, and once the zfcp adapter is either reset during recovery\nor shutdown we end up freeing the same memory twice.\n\nThe resulting stack traces vary depending on the kernel and have no direct\ncorrelation to the place where the bug occurs. Here are three examples that\nhave been seen in practice:\n\n  list_del corruption. next->prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00)\n  ------------[ cut here ]------------\n  kernel BUG at lib/list_debug.c:62!\n  monitor event: 0040 ilc:2 [#1] PREEMPT SMP\n  Modules linked in: ...\n  CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded\n  Hardware name: ...\n  Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140)\n             R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3\n  Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6\n             0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8\n             00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800\n             00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70\n  Krnl Code: 00000003cbeea1e8: c020004f68a7        larl    %r2,00000003cc8d7336\n             00000003cbeea1ee: c0e50027fd65        brasl   %r14,00000003cc3e9cb8\n            #00000003cbeea1f4: af000000            mc      0,0\n            >00000003cbeea1f8: c02000920440        larl    %r2,00000003cd12aa78\n             00000003cbeea1fe: c0e500289c25        brasl   %r14,00000003cc3fda48\n             00000003cbeea204: b9040043            lgr     %r4,%r3\n             00000003cbeea208: b9040051            lgr     %r5,%r1\n             00000003cbeea20c: b9040032            lgr     %r3,%r2\n  Call Trace:\n   [<00000003cbeea1f8>] __list_del_entry_valid+0x98/0x140\n  ([<00000003cbeea1f4>] __list_del_entry_valid+0x94/0x140)\n   [<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp]\n   [<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp]\n---truncated---"
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: zfcp: Arregla doble liberaci\u00f3n de solicitud FSF cuando falla el env\u00edo de qdio Sol\u00edamos usar el tipo incorrecto de entero en 'zfcp_fsf_req_send()' para almacenar en cach\u00e9 el ID de solicitud FSF al enviar una nueva solicitud FSF. Esto se usa en caso de que el env\u00edo falle y necesitemos eliminar la solicitud de nuestra tabla hash interna nuevamente (para no mantener una referencia no v\u00e1lida y usarla cuando liberemos la solicitud nuevamente). En 'zfcp_fsf_req_send()' sol\u00edamos almacenar en cach\u00e9 el ID como 'int' (con signo y 32 bits de ancho), pero el resto del c\u00f3digo zfcp (y la especificaci\u00f3n del firmware) maneja el ID como 'unsigned long'/'u64' (sin signo y 64 bits de ancho [s390x ELF ABI]). Por un lado, esto presenta el problema obvio de que, cuando el ID supera los 32 bits (esto puede ocurrir con relativa rapidez), se trunca a 32 bits al almacenarlo en la variable de cach\u00e9, por lo que ya no coincide con el ID original. El segundo problema, menos obvio, es que, incluso cuando el ID original a\u00fan no supera los 32 bits, en cuanto se establece el bit 32 en el ID original (0x80000000 = 2'147'483'648), se produce una discrepancia al convertirlo a 'unsigned long'. Como la variable en cach\u00e9 es de tipo con signo, el compilador utilizar\u00e1 una instrucci\u00f3n de extensi\u00f3n de signo para cargar la variable de 32 bits en un registro de 64 bits (p. ej., 'lgf %r11,188(%r15)'). Entonces, una vez que pasamos la variable en cach\u00e9 a 'zfcp_reqlist_find_rm()' para eliminar la solicitud de nuevo, todos los ceros iniciales se invertir\u00e1n a unos para extender el signo y ya no coincidir\u00e1n con el ID original (esto se ha observado en la pr\u00e1ctica). Si no podemos eliminar correctamente la solicitud de la tabla hash de nuevo despu\u00e9s de que 'zfcp_qdio_send()' falle (esto sucede regularmente cuando zfcp no puede notificar al adaptador sobre el nuevo trabajo porque el adaptador ya se ha ido durante, por ejemplo, una conmutaci\u00f3n de ChpID), terminaremos con una doble liberaci\u00f3n. Liberamos incondicionalmente la solicitud en la funci\u00f3n de llamada cuando 'zfcp_fsf_req_send()' falla, pero debido a que la solicitud a\u00fan est\u00e1 en la tabla hash, terminamos con una referencia de memoria obsoleta, y una vez que el adaptador zfcp se reinicia durante la recuperaci\u00f3n o el apagado, terminamos liberando la misma memoria dos veces. Los seguimientos de pila resultantes var\u00edan seg\u00fan el kernel y no tienen correlaci\u00f3n directa con el lugar donde ocurre el error. A continuaci\u00f3n se muestran tres ejemplos que se han visto en la pr\u00e1ctica: corrupci\u00f3n de list_del. next-&gt;prev deber\u00eda ser 00000001b9d13800, pero era 00000000dead4ead. (next=00000001bd131a00) ------------[ cortar aqu\u00ed ]------------ \u00a1ERROR del kernel en lib/list_debug.c:62! evento de monitor: 0040 ilc:2 [#1] PREEMPT M\u00f3dulos SMP vinculados: ... CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: cargado Nombre del hardware: ... Krnl PSW: 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140) R:0 T:1 IO:1 EX:1 Clave:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 00000000916d12f1 0000000080000000 00000000000006d 00000003cb665cd6 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70 C\u00f3digo Krnl: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8 #00000003cbeea1f4: af000000 mc 0,0 &gt;00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48 00000003cbeea204: b9040043 lgr %r4,%r3 00000003cbeea208: b9040051 lgr %r5,%r1 00000003cbeea20c: b9040032 lgr %r3,%r2 Rastreo de llamadas: [&lt;00000003cbeea1f8&gt;] __list_del_entry_valid+0x98/0x140 ([&lt;00000003cbeea1f4&gt;] __list_del_entry_valid+0x94/0x140) [&lt;000003ff7ff502fe&gt;] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp] [&lt;000003ff7ff49cd0&gt;] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp] ---truncado---"
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49790.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nInput: iforce - invert valid length check when fetching device IDs\n\nsyzbot is reporting uninitialized value at iforce_init_device() [1], for\ncommit 6ac0aec6b0a6 (\"Input: iforce - allow callers supply data buffer\nwhen fetching device IDs\") is checking that valid length is shorter than\nbytes to read. Since iforce_get_id_packet() stores valid length when\nreturning 0, the caller needs to check that valid length is longer than or\nequals to bytes to read."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Entrada: iforce - invierte la comprobaci\u00f3n de longitud v\u00e1lida al obtener los ID de dispositivo. syzbot informa un valor no inicializado en iforce_init_device() [1], para el commit 6ac0aec6b0a6 (\"Entrada: iforce - permite que los llamantes suministren el b\u00fafer de datos al obtener los ID de dispositivo\") y comprueba que la longitud v\u00e1lida sea menor que los bytes a leer. Dado que iforce_get_id_packet() almacena la longitud v\u00e1lida al devolver 0, el llamante debe comprobar que la longitud v\u00e1lida sea mayor o igual que los bytes a leer."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-497xx/CVE-2022-49791.json

@@ -9,6 +9,10 @@
     {
       "lang": "en",
       "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fix multishot accept request leaks\n\nHaving REQ_F_POLLED set doesn't guarantee that the request is\nexecuted as a multishot from the polling path. Fortunately for us, if\nthe code thinks it's multishot issue when it's not, it can only ask to\nskip completion so leaking the request. Use issue_flags to mark\nmultipoll issues."
+    },
+    {
+      "lang": "es",
+      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: correcci\u00f3n de fugas de solicitudes de aceptaci\u00f3n multishot. Tener REQ_F_POLLED configurado no garantiza que la solicitud se ejecute como multishot desde la ruta de sondeo. Afortunadamente, si el c\u00f3digo considera que se trata de un problema multishot cuando no lo es, solo puede solicitar omitir la finalizaci\u00f3n, lo que provoca la fuga de la solicitud. Use issue_flags para marcar los problemas de multipoll."
     }
   ],
   "metrics": {},

CVE-2022/CVE-2022-498xx/CVE-2022-49837.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:07.187",
   "lastModified": "2025-05-02T13:53:20.943",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49839.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:07.390",
   "lastModified": "2025-05-02T13:53:20.943",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49840.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:07.493",
   "lastModified": "2025-05-02T13:53:20.943",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49842.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:07.703",
   "lastModified": "2025-05-02T13:53:20.943",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49844.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:07.907",
   "lastModified": "2025-05-02T13:53:20.943",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49845.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:08.010",
   "lastModified": "2025-05-02T13:53:20.943",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49846.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:08.113",
   "lastModified": "2025-05-02T13:53:20.943",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49848.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:08.327",
   "lastModified": "2025-05-02T13:53:20.943",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49850.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:08.567",
   "lastModified": "2025-05-02T13:53:20.943",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49853.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:08.890",
   "lastModified": "2025-05-02T13:53:20.943",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49854.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:08.997",
   "lastModified": "2025-05-02T13:53:20.943",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49855.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:09.090",
   "lastModified": "2025-05-02T13:53:20.943",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49857.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:09.307",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49860.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:09.610",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49861.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:09.727",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49862.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:11.097",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49863.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:11.203",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49864.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:11.313",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49866.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:11.530",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49867.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:11.633",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49869.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:11.830",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49871.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:12.030",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49873.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:12.240",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49874.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:12.340",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49875.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:12.450",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49876.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:12.550",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49878.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:12.753",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49880.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:12.960",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49881.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:13.077",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49885.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:13.480",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49887.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:13.690",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49888.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:13.790",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49889.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:13.897",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49890.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:14.000",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49891.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:14.107",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49892.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:14.210",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49894.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:14.417",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49895.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:14.517",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49896.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:14.643",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49897.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:14.747",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-498xx/CVE-2022-49899.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:14.953",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-499xx/CVE-2022-49901.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:15.167",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-499xx/CVE-2022-49902.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:15.270",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-499xx/CVE-2022-49904.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:15.480",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-499xx/CVE-2022-49906.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:15.703",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {

CVE-2022/CVE-2022-499xx/CVE-2022-49908.json

@@ -3,7 +3,7 @@
   "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
   "published": "2025-05-01T15:16:15.920",
   "lastModified": "2025-05-02T13:52:51.693",
-  "vulnStatus": "Awaiting Analysis",
+  "vulnStatus": "Undergoing Analysis",
   "cveTags": [],
   "descriptions": [
     {