{"schema_version":"1.7.2","id":"OESA-2024-2296","modified":"2024-10-25T11:09:27Z","published":"2024-10-25T11:09:27Z","upstream":["CVE-2023-52889","CVE-2024-27397","CVE-2024-36012","CVE-2024-36015","CVE-2024-36032","CVE-2024-36244","CVE-2024-36880","CVE-2024-36889","CVE-2024-36894","CVE-2024-36909","CVE-2024-36910","CVE-2024-36911","CVE-2024-36913","CVE-2024-36915","CVE-2024-36918","CVE-2024-36920","CVE-2024-36921","CVE-2024-36922","CVE-2024-36927","CVE-2024-36936","CVE-2024-36940","CVE-2024-36941","CVE-2024-36946","CVE-2024-36963","CVE-2024-36971","CVE-2024-38594","CVE-2024-38608","CVE-2024-38612","CVE-2024-40999","CVE-2024-42104","CVE-2024-42128","CVE-2024-42157","CVE-2024-42229","CVE-2024-42232","CVE-2024-42236","CVE-2024-42280","CVE-2024-42283","CVE-2024-42286","CVE-2024-42287","CVE-2024-42289","CVE-2024-42290","CVE-2024-42292","CVE-2024-42295","CVE-2024-42299","CVE-2024-42305","CVE-2024-42306","CVE-2024-42308","CVE-2024-42309","CVE-2024-42311","CVE-2024-42313","CVE-2024-42322","CVE-2024-43823","CVE-2024-43828","CVE-2024-43830","CVE-2024-43831","CVE-2024-43834","CVE-2024-43840","CVE-2024-43860","CVE-2024-43892","CVE-2024-43893","CVE-2024-43894","CVE-2024-44931","CVE-2024-44952","CVE-2024-44990","CVE-2024-45018","CVE-2024-46676","CVE-2024-46689","CVE-2024-46691","CVE-2024-46709","CVE-2024-46716","CVE-2024-46726","CVE-2024-46754","CVE-2024-46795","CVE-2024-46805","CVE-2024-46810","CVE-2024-46817","CVE-2024-46819","CVE-2024-46821","CVE-2024-46822","CVE-2024-46826","CVE-2024-46830","CVE-2024-46836","CVE-2024-46838","CVE-2024-46840","CVE-2024-46854","CVE-2024-46855","CVE-2024-46858","CVE-2024-46859","CVE-2024-47658","CVE-2024-47665","CVE-2024-47669","CVE-2024-47671","CVE-2024-47672","CVE-2024-47675","CVE-2024-47731","CVE-2024-47741"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\napparmor: Fix null pointer deref when receiving skb during sock creation\r\n\r\nThe panic below is observed when receiving ICMP packets with secmark set\nwhile an ICMP raw socket is being created. SK_CTX(sk)-\u0026gt;label is updated\nin apparmor_socket_post_create(), but the packet is delivered to the\nsocket before that, causing the null pointer dereference.\nDrop the packet if label context is not set.\r\n\r\n    BUG: kernel NULL pointer dereference, address: 000000000000004c\n    #PF: supervisor read access in kernel mode\n    #PF: error_code(0x0000) - not-present page\n    PGD 0 P4D 0\n    Oops: 0000 [#1] PREEMPT SMP NOPTI\n    CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df\n    Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020\n    RIP: 0010:aa_label_next_confined+0xb/0x40\n    Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 \u0026lt;8b\u0026gt; 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2\n    RSP: 0018:ffffa92940003b08 EFLAGS: 00010246\n    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e\n    RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000\n    RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002\n    R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400\n    R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000\n    FS:  00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000\n    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0\n    PKRU: 55555554\n    Call Trace:\n     \u0026lt;IRQ\u0026gt;\n     ? __die+0x23/0x70\n     ? page_fault_oops+0x171/0x4e0\n     ? exc_page_fault+0x7f/0x180\n     ? asm_exc_page_fault+0x26/0x30\n     ? aa_label_next_confined+0xb/0x40\n     apparmor_secmark_check+0xec/0x330\n     security_sock_rcv_skb+0x35/0x50\n     sk_filter_trim_cap+0x47/0x250\n     sock_queue_rcv_skb_reason+0x20/0x60\n     raw_rcv+0x13c/0x210\n     raw_local_deliver+0x1f3/0x250\n     ip_protocol_deliver_rcu+0x4f/0x2f0\n     ip_local_deliver_finish+0x76/0xa0\n     __netif_receive_skb_one_core+0x89/0xa0\n     netif_receive_skb+0x119/0x170\n     ? __netdev_alloc_skb+0x3d/0x140\n     vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]\n     vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]\n     __napi_poll+0x28/0x1b0\n     net_rx_action+0x2a4/0x380\n     __do_softirq+0xd1/0x2c8\n     __irq_exit_rcu+0xbb/0xf0\n     common_interrupt+0x86/0xa0\n     \u0026lt;/IRQ\u0026gt;\n     \u0026lt;TASK\u0026gt;\n     asm_common_interrupt+0x26/0x40\n    RIP: 0010:apparmor_socket_post_create+0xb/0x200\n    Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 \u0026lt;55\u0026gt; 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48\n    RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286\n    RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001\n    RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740\n    RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000\n    R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003\n    R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748\n     ? __pfx_apparmor_socket_post_create+0x10/0x10\n     security_socket_post_create+0x4b/0x80\n     __sock_create+0x176/0x1f0\n     __sys_socket+0x89/0x100\n     __x64_sys_socket+0x17/0x20\n     do_syscall_64+0x5d/0x90\n     ? do_syscall_64+0x6c/0x90\n     ? do_syscall_64+0x6c/0x90\n     ? do_syscall_64+0x6c/0x90\n     entry_SYSCALL_64_after_hwframe+0x72/0xdc(CVE-2023-52889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: use timestamp to check for set element timeout\r\n\r\nAdd a timestamp field at the beginning of the transaction, store it\nin the nftables per-netns area.\r\n\r\nUpdate set backend .insert, .deactivate and sync gc path to use the\ntimestamp, this avoids that an element expires while control plane\ntransaction is still unfinished.\r\n\r\n.lookup and .update, which are used from packet path, still use the\ncurrent time to check if the element has expired. And .get path and dump\nalso since this runs lockless under rcu read size lock. Then, there is\nasync gc which also needs to check the current time since it runs\nasynchronously from a workqueue.(CVE-2024-27397)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: msft: fix slab-use-after-free in msft_do_close()\r\n\r\nTying the msft-\u0026gt;data lifetime to hdev by freeing it in\nhci_release_dev() to fix the following case:\r\n\r\n[use]\nmsft_do_close()\n  msft = hdev-\u0026gt;msft_data;\n  if (!msft)                      ...(1) \u0026lt;- passed.\n    return;\n  mutex_lock(\u0026amp;msft-\u0026gt;filter_lock); ...(4) \u0026lt;- used after freed.\r\n\r\n[free]\nmsft_unregister()\n  msft = hdev-\u0026gt;msft_data;\n  hdev-\u0026gt;msft_data = NULL;         ...(2)\n  kfree(msft);                    ...(3) \u0026lt;- msft is freed.\r\n\r\n==================================================================\nBUG: KASAN: slab-use-after-free in __mutex_lock_common\nkernel/locking/mutex.c:587 [inline]\nBUG: KASAN: slab-use-after-free in __mutex_lock+0x8f/0xc30\nkernel/locking/mutex.c:752\nRead of size 8 at addr ffff888106cbbca8 by task kworker/u5:2/309(CVE-2024-36012)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nppdev: Add an error check in register_device\r\n\r\nIn register_device, the return value of ida_simple_get is unchecked,\nin witch ida_simple_get will use an invalid index value.\r\n\r\nTo address this issue, index should be checked after ida_simple_get. When\nthe index value is abnormal, a warning message should be printed, the port\nshould be dropped, and the value should be recorded.(CVE-2024-36015)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: qca: fix info leak when fetching fw build id\r\n\r\nAdd the missing sanity checks and move the 255-byte build-id buffer off\nthe stack to avoid leaking stack data through debugfs in case the\nbuild-info reply is malformed.(CVE-2024-36032)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: taprio: extend minimum interval restriction to entire cycle too\r\n\r\nIt is possible for syzbot to side-step the restriction imposed by the\nblamed commit in the Fixes: tag, because the taprio UAPI permits a\ncycle-time different from (and potentially shorter than) the sum of\nentry intervals.\r\n\r\nWe need one more restriction, which is that the cycle time itself must\nbe larger than N * ETH_ZLEN bit times, where N is the number of schedule\nentries. This restriction needs to apply regardless of whether the cycle\ntime came from the user or was the implicit, auto-calculated value, so\nwe move the existing \u0026quot;cycle == 0\u0026quot; check outside the \u0026quot;if \u0026quot;(!new-\u0026gt;cycle_time)\u0026quot;\nbranch. This way covers both conditions and scenarios.\r\n\r\nAdd a selftest which illustrates the issue triggered by syzbot.(CVE-2024-36244)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: qca: add missing firmware sanity checks\r\n\r\nAdd the missing sanity checks when parsing the firmware files before\ndownloading them to avoid accessing and corrupting memory beyond the\nvmalloced buffer.(CVE-2024-36880)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: ensure snd_nxt is properly initialized on connect\r\n\r\nChristoph reported a splat hinting at a corrupted snd_una:\r\n\r\n  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005\n  Modules linked in:\n  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014\n  Workqueue: events mptcp_worker\n  RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005\n  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8\n  \t8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe\n  \t\u0026lt;0f\u0026gt; 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9\n  RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293\n  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4\n  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001\n  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\n  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000\n  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000\n  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]\n   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]\n   __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615\n   mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767\n   process_one_work+0x1e0/0x560 kernel/workqueue.c:3254\n   process_scheduled_works kernel/workqueue.c:3335 [inline]\n   worker_thread+0x3c7/0x640 kernel/workqueue.c:3416\n   kthread+0x121/0x170 kernel/kthread.c:388\n   ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147\n   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243\n   \u0026lt;/TASK\u0026gt;\r\n\r\nWhen fallback to TCP happens early on a client socket, snd_nxt\nis not yet initialized and any incoming ack will copy such value\ninto snd_una. If the mptcp worker (dumbly) tries mptcp-level\nre-injection after such ack, that would unconditionally trigger a send\nbuffer cleanup using \u0026apos;bad\u0026apos; snd_una values.\r\n\r\nWe could easily disable re-injection for fallback sockets, but such\ndumb behavior already helped catching a few subtle issues and a very\nlow to zero impact in practice.\r\n\r\nInstead address the issue always initializing snd_nxt (and write_seq,\nfor consistency) at connect time.(CVE-2024-36889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete\r\n\r\nFFS based applications can utilize the aio_cancel() callback to dequeue\npending USB requests submitted to the UDC.  There is a scenario where the\nFFS application issues an AIO cancel call, while the UDC is handling a\nsoft disconnect.  For a DWC3 based implementation, the callstack looks\nlike the following:\r\n\r\n    DWC3 Gadget                               FFS Application\ndwc3_gadget_soft_disconnect()              ...\n  --\u0026gt; dwc3_stop_active_transfers()\n    --\u0026gt; dwc3_gadget_giveback(-ESHUTDOWN)\n      --\u0026gt; ffs_epfile_async_io_complete()   ffs_aio_cancel()\n        --\u0026gt; usb_ep_free_request()            --\u0026gt; usb_ep_dequeue()\r\n\r\nThere is currently no locking implemented between the AIO completion\nhandler and AIO cancel, so the issue occurs if the completion routine is\nrunning in parallel to an AIO cancel call coming from the FFS application.\nAs the completion call frees the USB request (io_data-\u0026gt;req) the FFS\napplication is also referencing it for the usb_ep_dequeue() call.  This can\nlead to accessing a stale/hanging pointer.\r\n\r\ncommit b566d38857fc (\u0026quot;usb: gadget: f_fs: use io_data-\u0026gt;status consistently\u0026quot;)\nrelocated the usb_ep_free_request() into ffs_epfile_async_io_complete().\nHowever, in order to properly implement locking to mitigate this issue, the\nspinlock can\u0026apos;t be added to ffs_epfile_async_io_complete(), as\nusb_ep_dequeue() (if successfully dequeuing a USB request) will call the\nfunction driver\u0026apos;s completion handler in the same context.  Hence, leading\ninto a deadlock.\r\n\r\nFix this issue by moving the usb_ep_free_request() back to\nffs_user_copy_worker(), and ensuring that it explicitly sets io_data-\u0026gt;req\nto NULL after freeing it within the ffs-\u0026gt;eps_lock.  This resolves the race\ncondition above, as the ffs_aio_cancel() routine will not continue\nattempting to dequeue a request that has already been freed, or the\nffs_user_copy_work() not freeing the USB request until the AIO cancel is\ndone referencing it.\r\n\r\nThis fix depends on\n  commit b566d38857fc (\u0026quot;usb: gadget: f_fs: use io_data-\u0026gt;status\n  consistently\u0026quot;)(CVE-2024-36894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nDrivers: hv: vmbus: Don\u0026apos;t free ring buffers that couldn\u0026apos;t be re-encrypted\r\n\r\nIn CoCo VMs it is possible for the untrusted host to cause\nset_memory_encrypted() or set_memory_decrypted() to fail such that an\nerror is returned and the resulting memory is shared. Callers need to\ntake care to handle these errors to avoid returning decrypted (shared)\nmemory to the page allocator, which could lead to functional or security\nissues.\r\n\r\nThe VMBus ring buffer code could free decrypted/shared pages if\nset_memory_decrypted() fails. Check the decrypted field in the struct\nvmbus_gpadl for the ring buffers to decide whether to free the memory.(CVE-2024-36909)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nuio_hv_generic: Don\u0026apos;t free decrypted memory\r\n\r\nIn CoCo VMs it is possible for the untrusted host to cause\nset_memory_encrypted() or set_memory_decrypted() to fail such that an\nerror is returned and the resulting memory is shared. Callers need to\ntake care to handle these errors to avoid returning decrypted (shared)\nmemory to the page allocator, which could lead to functional or security\nissues.\r\n\r\nThe VMBus device UIO driver could free decrypted/shared pages if\nset_memory_decrypted() fails. Check the decrypted field in the gpadl\nto decide whether to free the memory.(CVE-2024-36910)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhv_netvsc: Don\u0026apos;t free decrypted memory\r\n\r\nIn CoCo VMs it is possible for the untrusted host to cause\nset_memory_encrypted() or set_memory_decrypted() to fail such that an\nerror is returned and the resulting memory is shared. Callers need to\ntake care to handle these errors to avoid returning decrypted (shared)\nmemory to the page allocator, which could lead to functional or security\nissues.\r\n\r\nThe netvsc driver could free decrypted/shared pages if\nset_memory_decrypted() fails. Check the decrypted field in the gpadl\nto decide whether to free the memory.(CVE-2024-36911)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nDrivers: hv: vmbus: Leak pages if set_memory_encrypted() fails\r\n\r\nIn CoCo VMs it is possible for the untrusted host to cause\nset_memory_encrypted() or set_memory_decrypted() to fail such that an\nerror is returned and the resulting memory is shared. Callers need to\ntake care to handle these errors to avoid returning decrypted (shared)\nmemory to the page allocator, which could lead to functional or security\nissues.\r\n\r\nVMBus code could free decrypted pages if set_memory_encrypted()/decrypted()\nfails. Leak the pages if this happens.(CVE-2024-36913)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: llcp: fix nfc_llcp_setsockopt() unsafe copies\r\n\r\nsyzbot reported unsafe calls to copy_from_sockptr() [1]\r\n\r\nUse copy_safe_from_sockptr() instead.\r\n\r\n[1]\r\n\r\nBUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]\n BUG: KASAN: slab-out-of-bounds in nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255\nRead of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078\r\n\r\nCPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n  print_address_description mm/kasan/report.c:377 [inline]\n  print_report+0x169/0x550 mm/kasan/report.c:488\n  kasan_report+0x143/0x180 mm/kasan/report.c:601\n  copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n  copy_from_sockptr include/linux/sockptr.h:55 [inline]\n  nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255\n  do_sock_setsockopt+0x3b1/0x720 net/socket.c:2311\n  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n  __do_sys_setsockopt net/socket.c:2343 [inline]\n  __se_sys_setsockopt net/socket.c:2340 [inline]\n  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfd/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\nRIP: 0033:0x7f7fac07fd89\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fff660eb788 EFLAGS: 00000246 ORIG_RAX: 0000000000000036\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89\nRDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004\nRBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000\nR10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000(CVE-2024-36915)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Check bloom filter map value size\r\n\r\nThis patch adds a missing check to bloom filter creating, rejecting\nvalues above KMALLOC_MAX_SIZE. This brings the bloom map in line with\nmany other map types.\r\n\r\nThe lack of this protection can cause kernel crashes for value sizes\nthat overflow int\u0026apos;s. Such a crash was caught by syzkaller. The next\npatch adds more guard-rails at a lower level.(CVE-2024-36918)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: mpi3mr: Avoid memcpy field-spanning write WARNING\r\n\r\nWhen the \u0026quot;storcli2 show\u0026quot; command is executed for eHBA-9600, mpi3mr driver\nprints this WARNING message:\r\n\r\n  memcpy: detected field-spanning write (size 128) of single field \u0026quot;bsg_reply_buf-\u0026gt;reply_buf\u0026quot; at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 (size 1)\n  WARNING: CPU: 0 PID: 12760 at drivers/scsi/mpi3mr/mpi3mr_app.c:1658 mpi3mr_bsg_request+0x6b12/0x7f10 [mpi3mr]\r\n\r\nThe cause of the WARN is 128 bytes memcpy to the 1 byte size array \u0026quot;__u8\nreplay_buf[1]\u0026quot; in the struct mpi3mr_bsg_in_reply_buf. The array is intended\nto be a flexible length array, so the WARN is a false positive.\r\n\r\nTo suppress the WARN, remove the constant number \u0026apos;1\u0026apos; from the array\ndeclaration and clarify that it has flexible length. Also, adjust the\nmemory allocation size to match the change.(CVE-2024-36920)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: mvm: guard against invalid STA ID on removal\r\n\r\nGuard against invalid station IDs in iwl_mvm_mld_rm_sta_id as that would\nresult in out-of-bounds array accesses. This prevents issues should the\ndriver get into a bad state during error handling.(CVE-2024-36921)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: read txq-\u0026gt;read_ptr under lock\r\n\r\nIf we read txq-\u0026gt;read_ptr without lock, we can read the same\nvalue twice, then obtain the lock, and reclaim from there\nto two different places, but crucially reclaim the same\nentry twice, resulting in the WARN_ONCE() a little later.\nFix that by reading txq-\u0026gt;read_ptr under lock.(CVE-2024-36922)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv4: Fix uninit-value access in __ip_make_skb()\r\n\r\nKMSAN reported uninit-value access in __ip_make_skb() [1].  __ip_make_skb()\ntests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a\nrace condition. If calling setsockopt(2) with IP_HDRINCL changes HDRINCL\nwhile __ip_make_skb() is running, the function will access icmphdr in the\nskb even if it is not included. This causes the issue reported by KMSAN.\r\n\r\nCheck FLOWI_FLAG_KNOWN_NH on fl4-\u0026gt;flowi4_flags instead of testing HDRINCL\non the socket.\r\n\r\nAlso, fl4-\u0026gt;fl4_icmp_type and fl4-\u0026gt;fl4_icmp_code are not initialized. These\nare union in struct flowi4 and are implicitly initialized by\nflowi4_init_output(), but we should not rely on specific union layout.\r\n\r\nInitialize these explicitly in raw_sendmsg().\r\n\r\n[1]\nBUG: KMSAN: uninit-value in __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481\n __ip_make_skb+0x2b74/0x2d20 net/ipv4/ip_output.c:1481\n ip_finish_skb include/net/ip.h:243 [inline]\n ip_push_pending_frames+0x4c/0x5c0 net/ipv4/ip_output.c:1508\n raw_sendmsg+0x2381/0x2690 net/ipv4/raw.c:654\n inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x274/0x3c0 net/socket.c:745\n __sys_sendto+0x62c/0x7b0 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x130/0x200 net/socket.c:2199\n do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3804 [inline]\n slab_alloc_node mm/slub.c:3845 [inline]\n kmem_cache_alloc_node+0x5f6/0xc50 mm/slub.c:3888\n kmalloc_reserve+0x13c/0x4a0 net/core/skbuff.c:577\n __alloc_skb+0x35a/0x7c0 net/core/skbuff.c:668\n alloc_skb include/linux/skbuff.h:1318 [inline]\n __ip_append_data+0x49ab/0x68c0 net/ipv4/ip_output.c:1128\n ip_append_data+0x1e7/0x260 net/ipv4/ip_output.c:1365\n raw_sendmsg+0x22b1/0x2690 net/ipv4/raw.c:648\n inet_sendmsg+0x27b/0x2a0 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x274/0x3c0 net/socket.c:745\n __sys_sendto+0x62c/0x7b0 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x130/0x200 net/socket.c:2199\n do_syscall_64+0xd8/0x1f0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nCPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014(CVE-2024-36927)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nefi/unaccepted: touch soft lockup during memory accept\r\n\r\nCommit 50e782a86c98 (\u0026quot;efi/unaccepted: Fix soft lockups caused by\nparallel memory acceptance\u0026quot;) has released the spinlock so other CPUs can\ndo memory acceptance in parallel and not triggers softlockup on other\nCPUs.\r\n\r\nHowever the softlock up was intermittent shown up if the memory of the\nTD guest is large, and the timeout of softlockup is set to 1 second:\r\n\r\n RIP: 0010:_raw_spin_unlock_irqrestore\n Call Trace:\n ? __hrtimer_run_queues\n \u0026lt;IRQ\u0026gt;\n ? hrtimer_interrupt\n ? watchdog_timer_fn\n ? __sysvec_apic_timer_interrupt\n ? __pfx_watchdog_timer_fn\n ? sysvec_apic_timer_interrupt\n \u0026lt;/IRQ\u0026gt;\n ? __hrtimer_run_queues\n \u0026lt;TASK\u0026gt;\n ? hrtimer_interrupt\n ? asm_sysvec_apic_timer_interrupt\n ? _raw_spin_unlock_irqrestore\n ? __sysvec_apic_timer_interrupt\n ? sysvec_apic_timer_interrupt\n accept_memory\n try_to_accept_memory\n do_huge_pmd_anonymous_page\n get_page_from_freelist\n __handle_mm_fault\n __alloc_pages\n __folio_alloc\n ? __tdx_hypercall\n handle_mm_fault\n vma_alloc_folio\n do_user_addr_fault\n do_huge_pmd_anonymous_page\n exc_page_fault\n ? __do_huge_pmd_anonymous_page\n asm_exc_page_fault\n __handle_mm_fault\r\n\r\nWhen the local irq is enabled at the end of accept_memory(), the\nsoftlockup detects that the watchdog on single CPU has not been fed for\na while. That is to say, even other CPUs will not be blocked by\nspinlock, the current CPU might be stunk with local irq disabled for a\nwhile, which hurts not only nmi watchdog but also softlockup.\r\n\r\nChao Gao pointed out that the memory accept could be time costly and\nthere was similar report before. Thus to avoid any softlocup detection\nduring this stage, give the softlockup a flag to skip the timeout check\nat the end of accept_memory(), by invoking touch_softlockup_watchdog().(CVE-2024-36936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npinctrl: core: delete incorrect free in pinctrl_enable()\r\n\r\nThe \u0026quot;pctldev\u0026quot; struct is allocated in devm_pinctrl_register_and_init().\nIt\u0026apos;s a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),\nso freeing it in pinctrl_enable() will lead to a double free.\r\n\r\nThe devm_pinctrl_dev_release() function frees the pindescs and destroys\nthe mutex as well.(CVE-2024-36940)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: nl80211: don\u0026apos;t free NULL coalescing rule\r\n\r\nIf the parsing fails, we can dereference a NULL pointer here.(CVE-2024-36941)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nphonet: fix rtm_phonet_notify() skb allocation\r\n\r\nfill_route() stores three components in the skb:\r\n\r\n- struct rtmsg\n- RTA_DST (u8)\n- RTA_OIF (u32)\r\n\r\nTherefore, rtm_phonet_notify() should use\r\n\r\nNLMSG_ALIGN(sizeof(struct rtmsg)) +\nnla_total_size(1) +\nnla_total_size(4)(CVE-2024-36946)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracefs: Reset permissions on remount if permissions are options\r\n\r\nThere\u0026apos;s an inconsistency with the way permissions are handled in tracefs.\nBecause the permissions are generated when accessed, they default to the\nroot inode\u0026apos;s permission if they were never set by the user. If the user\nsets the permissions, then a flag is set and the permissions are saved via\nthe inode (for tracefs files) or an internal attribute field (for\neventfs).\r\n\r\nBut if a remount happens that specify the permissions, all the files that\nwere not changed by the user gets updated, but the ones that were are not.\nIf the user were to remount the file system with a given permission, then\nall files and directories within that file system should be updated.\r\n\r\nThis can cause security issues if a file\u0026apos;s permission was updated but the\nadmin forgot about it. They could incorrectly think that remounting with\npermissions set would update all files, but miss some.\r\n\r\nFor example:\r\n\r\n # cd /sys/kernel/tracing\n # chgrp 1002 current_tracer\n # ls -l\n[..]\n -rw-r-----  1 root root 0 May  1 21:25 buffer_size_kb\n -rw-r-----  1 root root 0 May  1 21:25 buffer_subbuf_size_kb\n -r--r-----  1 root root 0 May  1 21:25 buffer_total_size_kb\n -rw-r-----  1 root lkp  0 May  1 21:25 current_tracer\n -rw-r-----  1 root root 0 May  1 21:25 dynamic_events\n -r--r-----  1 root root 0 May  1 21:25 dyn_ftrace_total_info\n -r--r-----  1 root root 0 May  1 21:25 enabled_functions\r\n\r\nWhere current_tracer now has group \u0026quot;lkp\u0026quot;.\r\n\r\n # mount -o remount,gid=1001 .\n # ls -l\n -rw-r-----  1 root tracing 0 May  1 21:25 buffer_size_kb\n -rw-r-----  1 root tracing 0 May  1 21:25 buffer_subbuf_size_kb\n -r--r-----  1 root tracing 0 May  1 21:25 buffer_total_size_kb\n -rw-r-----  1 root lkp     0 May  1 21:25 current_tracer\n -rw-r-----  1 root tracing 0 May  1 21:25 dynamic_events\n -r--r-----  1 root tracing 0 May  1 21:25 dyn_ftrace_total_info\n -r--r-----  1 root tracing 0 May  1 21:25 enabled_functions\r\n\r\nEverything changed but the \u0026quot;current_tracer\u0026quot;.\r\n\r\nAdd a new link list that keeps track of all the tracefs_inodes which has\nthe permission flags that tell if the file/dir should use the root inode\u0026apos;s\npermission or not. Then on remount, clear all the flags so that the\ndefault behavior of using the root inode\u0026apos;s permission is done for all\nfiles and directories.(CVE-2024-36963)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fix __dst_negative_advice() race\r\n\r\n__dst_negative_advice() does not enforce proper RCU rules when\nsk-\u0026gt;dst_cache must be cleared, leading to possible UAF.\r\n\r\nRCU rules are that we must first clear sk-\u0026gt;sk_dst_cache,\nthen call dst_release(old_dst).\r\n\r\nNote that sk_dst_reset(sk) is implementing this protocol correctly,\nwhile __dst_negative_advice() uses the wrong order.\r\n\r\nGiven that ip6_negative_advice() has special logic\nagainst RTF_CACHE, this means each of the three -\u0026gt;negative_advice()\nexisting methods must perform the sk_dst_reset() themselves.\r\n\r\nNote the check against NULL dst is centralized in\n__dst_negative_advice(), there is no need to duplicate\nit in various callbacks.\r\n\r\nMany thanks to Clement Lecigne for tracking this issue.\r\n\r\nThis old bug became visible after the blamed commit, using UDP sockets.(CVE-2024-36971)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: stmmac: move the EST lock to struct stmmac_priv\r\n\r\nReinitialize the whole EST structure would also reset the mutex\nlock which is embedded in the EST structure, and then trigger\nthe following warning. To address this, move the lock to struct\nstmmac_priv. We also need to reacquire the mutex lock when doing\nthis initialization.\r\n\r\nDEBUG_LOCKS_WARN_ON(lock-\u0026gt;magic != lock)\nWARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068\n Modules linked in:\n CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29\n Hardware name: NXP i.MX8MPlus EVK board (DT)\n pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __mutex_lock+0xd84/0x1068\n lr : __mutex_lock+0xd84/0x1068\n sp : ffffffc0864e3570\n x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003\n x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac\n x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000\n x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff\n x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000\n x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8\n x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698\n x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001\n x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027\n x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000\n Call trace:\n  __mutex_lock+0xd84/0x1068\n  mutex_lock_nested+0x28/0x34\n  tc_setup_taprio+0x118/0x68c\n  stmmac_setup_tc+0x50/0xf0\n  taprio_change+0x868/0xc9c(CVE-2024-38594)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: Fix netif state handling\r\n\r\nmlx5e_suspend cleans resources only if netif_device_present() returns\ntrue. However, mlx5e_resume changes the state of netif, via\nmlx5e_nic_enable, only if reg_state == NETREG_REGISTERED.\nIn the below case, the above leads to NULL-ptr Oops[1] and memory\nleaks:\r\n\r\nmlx5e_probe\n _mlx5e_resume\n  mlx5e_attach_netdev\n   mlx5e_nic_enable  \u0026lt;-- netdev not reg, not calling netif_device_attach()\n  register_netdev \u0026lt;-- failed for some reason.\nERROR_FLOW:\n _mlx5e_suspend \u0026lt;-- netif_device_present return false, resources aren\u0026apos;t freed :(\r\n\r\nHence, clean resources in this case as well.\r\n\r\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nPGD 0 P4D 0\nOops: 0010 [#1] SMP\nCPU: 2 PID: 9345 Comm: test-ovs-ct-gen Not tainted 6.5.0_for_upstream_min_debug_2023_09_05_16_01 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:0x0\nCode: Unable to access opcode bytes at0xffffffffffffffd6.\nRSP: 0018:ffff888178aaf758 EFLAGS: 00010246\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x20/0x60\n ? page_fault_oops+0x14c/0x3c0\n ? exc_page_fault+0x75/0x140\n ? asm_exc_page_fault+0x22/0x30\n notifier_call_chain+0x35/0xb0\n blocking_notifier_call_chain+0x3d/0x60\n mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core]\n mlx5_core_uplink_netdev_event_replay+0x3e/0x60 [mlx5_core]\n mlx5_mdev_netdev_track+0x53/0x60 [mlx5_ib]\n mlx5_ib_roce_init+0xc3/0x340 [mlx5_ib]\n __mlx5_ib_add+0x34/0xd0 [mlx5_ib]\n mlx5r_probe+0xe1/0x210 [mlx5_ib]\n ? auxiliary_match_id+0x6a/0x90\n auxiliary_bus_probe+0x38/0x80\n ? driver_sysfs_add+0x51/0x80\n really_probe+0xc9/0x3e0\n ? driver_probe_device+0x90/0x90\n __driver_probe_device+0x80/0x160\n driver_probe_device+0x1e/0x90\n __device_attach_driver+0x7d/0x100\n bus_for_each_drv+0x80/0xd0\n __device_attach+0xbc/0x1f0\n bus_probe_device+0x86/0xa0\n device_add+0x637/0x840\n __auxiliary_device_add+0x3b/0xa0\n add_adev+0xc9/0x140 [mlx5_core]\n mlx5_rescan_drivers_locked+0x22a/0x310 [mlx5_core]\n mlx5_register_device+0x53/0xa0 [mlx5_core]\n mlx5_init_one_devl_locked+0x5c4/0x9c0 [mlx5_core]\n mlx5_init_one+0x3b/0x60 [mlx5_core]\n probe_one+0x44c/0x730 [mlx5_core]\n local_pci_probe+0x3e/0x90\n pci_device_probe+0xbf/0x210\n ? kernfs_create_link+0x5d/0xa0\n ? sysfs_do_create_link_sd+0x60/0xc0\n really_probe+0xc9/0x3e0\n ? driver_probe_device+0x90/0x90\n __driver_probe_device+0x80/0x160\n driver_probe_device+0x1e/0x90\n __device_attach_driver+0x7d/0x100\n bus_for_each_drv+0x80/0xd0\n __device_attach+0xbc/0x1f0\n pci_bus_add_device+0x54/0x80\n pci_iov_add_virtfn+0x2e6/0x320\n sriov_enable+0x208/0x420\n mlx5_core_sriov_configure+0x9e/0x200 [mlx5_core]\n sriov_numvfs_store+0xae/0x1a0\n kernfs_fop_write_iter+0x10c/0x1a0\n vfs_write+0x291/0x3c0\n ksys_write+0x5f/0xe0\n do_syscall_64+0x3d/0x90\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n CR2: 0000000000000000\n ---[ end trace 0000000000000000  ]---(CVE-2024-38608)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: sr: fix invalid unregister error path\r\n\r\nThe error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL\nis not defined. In that case if seg6_hmac_init() fails, the\ngenl_unregister_family() isn\u0026apos;t called.\r\n\r\nThis issue exist since commit 46738b1317e1 (\u0026quot;ipv6: sr: add option to control\nlwtunnel support\u0026quot;), and commit 5559cea2d5aa (\u0026quot;ipv6: sr: fix possible\nuse-after-free and null-ptr-deref\u0026quot;) replaced unregister_pernet_subsys()\nwith genl_unregister_family() in this error path.(CVE-2024-38612)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ena: Add validation for completion descriptors consistency\r\n\r\nValidate that `first` flag is set only for the first\ndescriptor in multi-buffer packets.\nIn case of an invalid descriptor, a reset will occur.\nA new reset reason for RX data corruption has been added.(CVE-2024-40999)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: add missing check for inode numbers on directory entries\r\n\r\nSyzbot reported that mounting and unmounting a specific pattern of\ncorrupted nilfs2 filesystem images causes a use-after-free of metadata\nfile inodes, which triggers a kernel bug in lru_add_fn().\r\n\r\nAs Jan Kara pointed out, this is because the link count of a metadata file\ngets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),\ntries to delete that inode (ifile inode in this case).\r\n\r\nThe inconsistency occurs because directories containing the inode numbers\nof these metadata files that should not be visible in the namespace are\nread without checking.\r\n\r\nFix this issue by treating the inode numbers of these internal files as\nerrors in the sanity check helper when reading directory folios/pages.\r\n\r\nAlso thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer\nanalysis.(CVE-2024-42104)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nleds: an30259a: Use devm_mutex_init() for mutex initialization\r\n\r\nIn this driver LEDs are registered using devm_led_classdev_register()\nso they are automatically unregistered after module\u0026apos;s remove() is done.\nled_classdev_unregister() calls module\u0026apos;s led_set_brightness() to turn off\nthe LEDs and that callback uses mutex which was destroyed already\nin module\u0026apos;s remove() so use devm API instead.(CVE-2024-42128)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/pkey: Wipe sensitive data on failure\r\n\r\nWipe sensitive data from stack also if the copy_to_user() fails.(CVE-2024-42157)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: aead,cipher - zeroize key buffer after use\r\n\r\nI.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding\ncryptographic information should be zeroized once they are no longer\nneeded. Accomplish this by using kfree_sensitive for buffers that\npreviously held the private key.(CVE-2024-42229)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlibceph: fix race between delayed_work() and ceph_monc_stop()\r\n\r\nThe way the delayed work is handled in ceph_monc_stop() is prone to\nraces with mon_fault() and possibly also finish_hunting().  Both of\nthese can requeue the delayed work which wouldn\u0026apos;t be canceled by any of\nthe following code in case that happens after cancel_delayed_work_sync()\nruns -- __close_session() doesn\u0026apos;t mess with the delayed work in order\nto avoid interfering with the hunting interval logic.  This part was\nmissed in commit b5d91704f53e (\u0026quot;libceph: behave in mon_fault() if\ncur_mon \u0026lt; 0\u0026quot;) and use-after-free can still ensue on monc and objects\nthat hang off of it, with monc-\u0026gt;auth and monc-\u0026gt;monmap being\nparticularly susceptible to quickly being reused.\r\n\r\nTo fix this:\r\n\r\n- clear monc-\u0026gt;cur_mon and monc-\u0026gt;hunting as part of closing the session\n  in ceph_monc_stop()\n- bail from delayed_work() if monc-\u0026gt;cur_mon is cleared, similar to how\n  it\u0026apos;s done in mon_fault() and finish_hunting() (based on monc-\u0026gt;hunting)\n- call cancel_delayed_work_sync() after the session is closed(CVE-2024-42232)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: configfs: Prevent OOB read/write in usb_string_copy()\r\n\r\nUserspace provided string \u0026apos;s\u0026apos; could trivially have the length zero. Left\nunchecked this will firstly result in an OOB read in the form\n`if (str[0 - 1] == \u0026apos;\\n\u0026apos;) followed closely by an OOB write in the form\n`str[0 - 1] = \u0026apos;\\0\u0026apos;`.\r\n\r\nThere is already a validating check to catch strings that are too long.\nLet\u0026apos;s supply an additional check for invalid strings that are too short.(CVE-2024-42236)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmISDN: Fix a use after free in hfcmulti_tx()\r\n\r\nDon\u0026apos;t dereference *sp after calling dev_kfree_skb(*sp).(CVE-2024-42280)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: nexthop: Initialize all fields in dumped nexthops\r\n\r\nstruct nexthop_grp contains two reserved fields that are not initialized by\nnla_put_nh_group(), and carry garbage. This can be observed e.g. with\nstrace (edited for clarity):\r\n\r\n    # ip nexthop add id 1 dev lo\n    # ip nexthop add id 101 group 1\n    # strace -e recvmsg ip nexthop get id 101\n    ...\n    recvmsg(... [{nla_len=12, nla_type=NHA_GROUP},\n                 [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52\r\n\r\nThe fields are reserved and therefore not currently used. But as they are, they\nleak kernel memory, and the fact they are not just zero complicates repurposing\nof the fields for new ends. Initialize the full structure.(CVE-2024-42283)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: validate nvme_local_port correctly\r\n\r\nThe driver load failed with error message,\r\n\r\nqla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef\r\n\r\nand with a kernel crash,\r\n\r\n\tBUG: unable to handle kernel NULL pointer dereference at 0000000000000070\n\tWorkqueue: events_unbound qla_register_fcport_fn [qla2xxx]\n\tRIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]\n\tRSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282\n\tRAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000\n\tRDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000\n\tRBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030\n\tR10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4\n\tR13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8\n\tFS:  0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000\n\tCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n\tCR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0\n\tCall Trace:\n\tqla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]\n\t? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]\n\tqla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]\n\tqla_register_fcport_fn+0x54/0xc0 [qla2xxx]\r\n\r\nExit the qla_nvme_register_remote() function when qla_nvme_register_hba()\nfails and correctly validate nvme_local_port.(CVE-2024-42286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: Complete command early within lock\r\n\r\nA crash was observed while performing NPIV and FW reset,\r\n\r\n BUG: kernel NULL pointer dereference, address: 000000000000001c\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 1 PREEMPT_RT SMP NOPTI\n RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0\n RSP: 0018:ffffc90026f47b88 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000002\n RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8881041130d0\n RBP: ffff8881041130d0 R08: 0000000000000000 R09: 0000000000000034\n R10: ffffc90026f47c48 R11: 0000000000000031 R12: 0000000000000000\n R13: 0000000000000000 R14: ffff8881565e4a20 R15: 0000000000000000\n FS: 00007f4c69ed3d00(0000) GS:ffff889faac80000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000000000001c CR3: 0000000288a50002 CR4: 00000000007706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x16f/0x4a0\n ? do_user_addr_fault+0x174/0x7f0\n ? exc_page_fault+0x69/0x1a0\n ? asm_exc_page_fault+0x22/0x30\n ? dma_direct_unmap_sg+0x51/0x1e0\n ? preempt_count_sub+0x96/0xe0\n qla2xxx_qpair_sp_free_dma+0x29f/0x3b0 [qla2xxx]\n qla2xxx_qpair_sp_compl+0x60/0x80 [qla2xxx]\n __qla2x00_abort_all_cmds+0xa2/0x450 [qla2xxx]\r\n\r\nThe command completion was done early while aborting the commands in driver\nunload path but outside lock to avoid the WARN_ON condition of performing\ndma_free_attr within the lock. However this caused race condition while\ncommand completion via multiple paths causing system crash.\r\n\r\nHence complete the command early in unload path but within the lock to\navoid race condition.(CVE-2024-42287)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: During vport delete send async logout explicitly\r\n\r\nDuring vport delete, it is observed that during unload we hit a crash\nbecause of stale entries in outstanding command array.  For all these stale\nI/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but\nI/Os could not complete while vport delete is in process of deleting.\r\n\r\n  BUG: kernel NULL pointer dereference, address: 000000000000001c\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 0 P4D 0\n  Oops: 0000 [#1] PREEMPT SMP NOPTI\n  Workqueue: qla2xxx_wq qla_do_work [qla2xxx]\n  RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0\n  RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046\n  RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001\n  RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0\n  RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8\n  R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000\n  R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000\n  FS:  0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0\n  Call Trace:\n  \u0026lt;TASK\u0026gt;\n  qla2xxx_qpair_sp_free_dma+0x417/0x4e0\n  ? qla2xxx_qpair_sp_compl+0x10d/0x1a0\n  ? qla2x00_status_entry+0x768/0x2830\n  ? newidle_balance+0x2f0/0x430\n  ? dequeue_entity+0x100/0x3c0\n  ? qla24xx_process_response_queue+0x6a1/0x19e0\n  ? __schedule+0x2d5/0x1140\n  ? qla_do_work+0x47/0x60\n  ? process_one_work+0x267/0x440\n  ? process_one_work+0x440/0x440\n  ? worker_thread+0x2d/0x3d0\n  ? process_one_work+0x440/0x440\n  ? kthread+0x156/0x180\n  ? set_kthread_struct+0x50/0x50\n  ? ret_from_fork+0x22/0x30\n  \u0026lt;/TASK\u0026gt;\r\n\r\nSend out async logout explicitly for all the ports during vport delete.(CVE-2024-42289)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nirqchip/imx-irqsteer: Handle runtime power management correctly\r\n\r\nThe power domain is automatically activated from clk_prepare(). However, on\ncertain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes\nsleeping functions, which triggers the \u0026apos;scheduling while atomic\u0026apos; bug in the\ncontext switch path during device probing:\r\n\r\n BUG: scheduling while atomic: kworker/u13:1/48/0x00000002\n Call trace:\n  __schedule_bug+0x54/0x6c\n  __schedule+0x7f0/0xa94\n  schedule+0x5c/0xc4\n  schedule_preempt_disabled+0x24/0x40\n  __mutex_lock.constprop.0+0x2c0/0x540\n  __mutex_lock_slowpath+0x14/0x20\n  mutex_lock+0x48/0x54\n  clk_prepare_lock+0x44/0xa0\n  clk_prepare+0x20/0x44\n  imx_irqsteer_resume+0x28/0xe0\n  pm_generic_runtime_resume+0x2c/0x44\n  __genpd_runtime_resume+0x30/0x80\n  genpd_runtime_resume+0xc8/0x2c0\n  __rpm_callback+0x48/0x1d8\n  rpm_callback+0x6c/0x78\n  rpm_resume+0x490/0x6b4\n  __pm_runtime_resume+0x50/0x94\n  irq_chip_pm_get+0x2c/0xa0\n  __irq_do_set_handler+0x178/0x24c\n  irq_set_chained_handler_and_data+0x60/0xa4\n  mxc_gpio_probe+0x160/0x4b0\r\n\r\nCure this by implementing the irq_bus_lock/sync_unlock() interrupt chip\ncallbacks and handle power management in them as they are invoked from\nnon-atomic context.\r\n\r\n[ tglx: Rewrote change log, added Fixes tag ](CVE-2024-42290)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkobject_uevent: Fix OOB access within zap_modalias_env()\r\n\r\nzap_modalias_env() wrongly calculates size of memory block to move, so\nwill cause OOB memory access issue if variable MODALIAS is not the last\none within its @env parameter, fixed by correcting size to memmove.(CVE-2024-42292)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: handle inconsistent state in nilfs_btnode_create_block()\r\n\r\nSyzbot reported that a buffer state inconsistency was detected in\nnilfs_btnode_create_block(), triggering a kernel bug.\r\n\r\nIt is not appropriate to treat this inconsistency as a bug; it can occur\nif the argument block address (the buffer index of the newly created\nblock) is a virtual block number and has been reallocated due to\ncorruption of the bitmap used to manage its allocation state.\r\n\r\nSo, modify nilfs_btnode_create_block() and its callers to treat it as a\npossible filesystem error, rather than triggering a kernel bug.(CVE-2024-42295)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/ntfs3: Update log-\u0026gt;page_{mask,bits} if log-\u0026gt;page_size changed\r\n\r\nIf an NTFS file system is mounted to another system with different\nPAGE_SIZE from the original system, log-\u0026gt;page_size will change in\nlog_replay(), but log-\u0026gt;page_{mask,bits} don\u0026apos;t change correspondingly.\nThis will cause a panic because \u0026quot;u32 bytes = log-\u0026gt;page_size - page_off\u0026quot;\nwill get a negative value in the later read_log_page().(CVE-2024-42299)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: check dot and dotdot of dx_root before making dir indexed\r\n\r\nSyzbot reports a issue as follows:\n============================================\nBUG: unable to handle page fault for address: ffffed11022e24fe\nPGD 23ffee067 P4D 23ffee067 PUD 0\nOops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341\n ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451\n ext4_rename fs/ext4/namei.c:3936 [inline]\n ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214\n[...]\n============================================\r\n\r\nThe immediate cause of this problem is that there is only one valid dentry\nfor the block to be split during do_split, so split==0 results in out of\nbounds accesses to the map triggering the issue.\r\n\r\n    do_split\n      unsigned split\n      dx_make_map\n       count = 1\n      split = count/2 = 0;\n      continued = hash2 == map[split - 1].hash;\n       ---\u0026gt; map[4294967295]\r\n\r\nThe maximum length of a filename is 255 and the minimum block size is 1024,\nso it is always guaranteed that the number of entries is greater than or\nequal to 2 when do_split() is called.\r\n\r\nBut syzbot\u0026apos;s crafted image has no dot and dotdot in dir, and the dentry\ndistribution in dirblock is as follows:\r\n\r\n  bus     dentry1          hole           dentry2           free\n|xx--|xx-------------|...............|xx-------------|...............|\n0   12 (8+248)=256  268     256     524 (8+256)=264 788     236     1024\r\n\r\nSo when renaming dentry1 increases its name_len length by 1, neither hole\nnor free is sufficient to hold the new dentry, and make_indexed_dir() is\ncalled.\r\n\r\nIn make_indexed_dir() it is assumed that the first two entries of the\ndirblock must be dot and dotdot, so bus and dentry1 are left in dx_root\nbecause they are treated as dot and dotdot, and only dentry2 is moved\nto the new leaf block. That\u0026apos;s why count is equal to 1.\r\n\r\nTherefore add the ext4_check_dx_root() helper function to add more sanity\nchecks to dot and dotdot before starting the conversion to avoid the above\nissue.(CVE-2024-42305)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nudf: Avoid using corrupted block bitmap buffer\r\n\r\nWhen the filesystem block bitmap is corrupted, we detect the corruption\nwhile loading the bitmap and fail the allocation with error. However the\nnext allocation from the same bitmap will notice the bitmap buffer is\nalready loaded and tries to allocate from the bitmap with mixed results\n(depending on the exact nature of the bitmap corruption). Fix the\nproblem by using BH_verified bit to indicate whether the bitmap is valid\nor not.(CVE-2024-42306)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-42308)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes\r\n\r\nIn psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a possible NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42309)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode()\r\n\r\nSyzbot reports uninitialized value access issue as below:\r\n\r\nloop0: detected capacity change from 0 to 64\n=====================================================\nBUG: KMSAN: uninit-value in hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30\n hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30\n d_revalidate fs/namei.c:862 [inline]\n lookup_fast+0x89e/0x8e0 fs/namei.c:1649\n walk_component fs/namei.c:2001 [inline]\n link_path_walk+0x817/0x1480 fs/namei.c:2332\n path_lookupat+0xd9/0x6f0 fs/namei.c:2485\n filename_lookup+0x22e/0x740 fs/namei.c:2515\n user_path_at_empty+0x8b/0x390 fs/namei.c:2924\n user_path_at include/linux/namei.h:57 [inline]\n do_mount fs/namespace.c:3689 [inline]\n __do_sys_mount fs/namespace.c:3898 [inline]\n __se_sys_mount+0x66b/0x810 fs/namespace.c:3875\n __x64_sys_mount+0xe4/0x140 fs/namespace.c:3875\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nBUG: KMSAN: uninit-value in hfs_ext_read_extent fs/hfs/extent.c:196 [inline]\nBUG: KMSAN: uninit-value in hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366\n hfs_ext_read_extent fs/hfs/extent.c:196 [inline]\n hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366\n block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271\n hfs_read_folio+0x55/0x60 fs/hfs/inode.c:39\n filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426\n do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553\n do_read_cache_page mm/filemap.c:3595 [inline]\n read_cache_page+0xfb/0x2f0 mm/filemap.c:3604\n read_mapping_page include/linux/pagemap.h:755 [inline]\n hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78\n hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204\n hfs_fill_super+0x1fb1/0x2790 fs/hfs/super.c:406\n mount_bdev+0x628/0x920 fs/super.c:1359\n hfs_mount+0xcd/0xe0 fs/hfs/super.c:456\n legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610\n vfs_get_tree+0xdc/0x5d0 fs/super.c:1489\n do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145\n path_mount+0xf98/0x26a0 fs/namespace.c:3475\n do_mount fs/namespace.c:3488 [inline]\n __do_sys_mount fs/namespace.c:3697 [inline]\n __se_sys_mount+0x919/0x9e0 fs/namespace.c:3674\n __ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674\n do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]\n __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178\n do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246\n entry_SYSENTER_compat_after_hwframe+0x70/0x82\r\n\r\nUninit was created at:\n __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590\n __alloc_pages_node include/linux/gfp.h:238 [inline]\n alloc_pages_node include/linux/gfp.h:261 [inline]\n alloc_slab_page mm/slub.c:2190 [inline]\n allocate_slab mm/slub.c:2354 [inline]\n new_slab+0x2d7/0x1400 mm/slub.c:2407\n ___slab_alloc+0x16b5/0x3970 mm/slub.c:3540\n __slab_alloc mm/slub.c:3625 [inline]\n __slab_alloc_node mm/slub.c:3678 [inline]\n slab_alloc_node mm/slub.c:3850 [inline]\n kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879\n alloc_inode_sb include/linux/fs.h:3018 [inline]\n hfs_alloc_inode+0x5a/0xc0 fs/hfs/super.c:165\n alloc_inode+0x83/0x440 fs/inode.c:260\n new_inode_pseudo fs/inode.c:1005 [inline]\n new_inode+0x38/0x4f0 fs/inode.c:1031\n hfs_new_inode+0x61/0x1010 fs/hfs/inode.c:186\n hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228\n vfs_mkdir+0x49a/0x700 fs/namei.c:4126\n do_mkdirat+0x529/0x810 fs/namei.c:4149\n __do_sys_mkdirat fs/namei.c:4164 [inline]\n __se_sys_mkdirat fs/namei.c:4162 [inline]\n __x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nIt missed to initialize .tz_secondswest, .cached_start and .cached_blocks\nfields in struct hfs_inode_info after hfs_alloc_inode(), fix it.(CVE-2024-42311)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: venus: fix use after free in vdec_close\r\n\r\nThere appears to be a possible use after free with vdec_close().\nThe firmware will add buffer release work to the work queue through\nHFI callbacks as a normal part of decoding. Randomly closing the\ndecoder device from userspace during normal decoding can incur\na read after free for inst.\r\n\r\nFix it by cancelling the work in vdec_close.(CVE-2024-42313)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipvs: properly dereference pe in ip_vs_add_service\r\n\r\nUse pe directly to resolve sparse warning:\r\n\r\n  net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression(CVE-2024-42322)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: keystone: Fix NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs()\r\n\r\nIf IORESOURCE_MEM is not provided in Device Tree due to\nany error, resource_list_first_type() will return NULL and\npci_parse_request_of_pci_ranges() will just emit a warning.\r\n\r\nThis will cause a NULL pointer dereference. Fix this bug by adding NULL\nreturn check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-43823)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: fix infinite loop when replaying fast_commit\r\n\r\nWhen doing fast_commit replay an infinite loop may occur due to an\nuninitialized extent_status struct.  ext4_ext_determine_insert_hole() does\nnot detect the replay and calls ext4_es_find_extent_range(), which will\nreturn immediately without initializing the \u0026apos;es\u0026apos; variable.\r\n\r\nBecause \u0026apos;es\u0026apos; contains garbage, an integer overflow may happen causing an\ninfinite loop in this function, easily reproducible using fstest generic/039.\r\n\r\nThis commit fixes this issue by unconditionally initializing the structure\nin function ext4_es_find_extent_range().\r\n\r\nThanks to Zhang Yi, for figuring out the real problem!(CVE-2024-43828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nleds: trigger: Unregister sysfs attributes before calling deactivate()\r\n\r\nTriggers which have trigger specific sysfs attributes typically store\nrelated data in trigger-data allocated by the activate() callback and\nfreed by the deactivate() callback.\r\n\r\nCalling device_remove_groups() after calling deactivate() leaves a window\nwhere the sysfs attributes show/store functions could be called after\ndeactivation and then operate on the just freed trigger-data.\r\n\r\nMove the device_remove_groups() call to before deactivate() to close\nthis race window.\r\n\r\nThis also makes the deactivation path properly do things in reverse order\nof the activation path which calls the activate() callback before calling\ndevice_add_groups().(CVE-2024-43830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: mediatek: vcodec: Handle invalid decoder vsi\r\n\r\nHandle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsi\nis valid for future use.(CVE-2024-43831)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxdp: fix invalid wait context of page_pool_destroy()\r\n\r\nIf the driver uses a page pool, it creates a page pool with\npage_pool_create().\nThe reference count of page pool is 1 as default.\nA page pool will be destroyed only when a reference count reaches 0.\npage_pool_destroy() is used to destroy page pool, it decreases a\nreference count.\nWhen a page pool is destroyed, -\u0026gt;disconnect() is called, which is\nmem_allocator_disconnect().\nThis function internally acquires mutex_lock().\r\n\r\nIf the driver uses XDP, it registers a memory model with\nxdp_rxq_info_reg_mem_model().\nThe xdp_rxq_info_reg_mem_model() internally increases a page pool\nreference count if a memory model is a page pool.\nNow the reference count is 2.\r\n\r\nTo destroy a page pool, the driver should call both page_pool_destroy()\nand xdp_unreg_mem_model().\nThe xdp_unreg_mem_model() internally calls page_pool_destroy().\nOnly page_pool_destroy() decreases a reference count.\r\n\r\nIf a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we\nwill face an invalid wait context warning.\nBecause xdp_unreg_mem_model() calls page_pool_destroy() with\nrcu_read_lock().\nThe page_pool_destroy() internally acquires mutex_lock().\r\n\r\nSplat looks like:\n=============================\n[ BUG: Invalid wait context ]\n6.10.0-rc6+ #4 Tainted: G W\n-----------------------------\nethtool/1806 is trying to lock:\nffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150\nother info that might help us debug this:\ncontext-{5:5}\n3 locks held by ethtool/1806:\nstack backtrace:\nCPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed\nHardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x7e/0xc0\n__lock_acquire+0x1681/0x4de0\n? _printk+0x64/0xe0\n? __pfx_mark_lock.part.0+0x10/0x10\n? __pfx___lock_acquire+0x10/0x10\nlock_acquire+0x1b3/0x580\n? mem_allocator_disconnect+0x73/0x150\n? __wake_up_klogd.part.0+0x16/0xc0\n? __pfx_lock_acquire+0x10/0x10\n? dump_stack_lvl+0x91/0xc0\n__mutex_lock+0x15c/0x1690\n? mem_allocator_disconnect+0x73/0x150\n? __pfx_prb_read_valid+0x10/0x10\n? mem_allocator_disconnect+0x73/0x150\n? __pfx_llist_add_batch+0x10/0x10\n? console_unlock+0x193/0x1b0\n? lockdep_hardirqs_on+0xbe/0x140\n? __pfx___mutex_lock+0x10/0x10\n? tick_nohz_tick_stopped+0x16/0x90\n? __irq_work_queue_local+0x1e5/0x330\n? irq_work_queue+0x39/0x50\n? __wake_up_klogd.part.0+0x79/0xc0\n? mem_allocator_disconnect+0x73/0x150\nmem_allocator_disconnect+0x73/0x150\n? __pfx_mem_allocator_disconnect+0x10/0x10\n? mark_held_locks+0xa5/0xf0\n? rcu_is_watching+0x11/0xb0\npage_pool_release+0x36e/0x6d0\npage_pool_destroy+0xd7/0x440\nxdp_unreg_mem_model+0x1a7/0x2a0\n? __pfx_xdp_unreg_mem_model+0x10/0x10\n? kfree+0x125/0x370\n? bnxt_free_ring.isra.0+0x2eb/0x500\n? bnxt_free_mem+0x5ac/0x2500\nxdp_rxq_info_unreg+0x4a/0xd0\nbnxt_free_mem+0x1356/0x2500\nbnxt_close_nic+0xf0/0x3b0\n? __pfx_bnxt_close_nic+0x10/0x10\n? ethnl_parse_bit+0x2c6/0x6d0\n? __pfx___nla_validate_parse+0x10/0x10\n? __pfx_ethnl_parse_bit+0x10/0x10\nbnxt_set_features+0x2a8/0x3e0\n__netdev_update_features+0x4dc/0x1370\n? ethnl_parse_bitset+0x4ff/0x750\n? __pfx_ethnl_parse_bitset+0x10/0x10\n? __pfx___netdev_update_features+0x10/0x10\n? mark_held_locks+0xa5/0xf0\n? _raw_spin_unlock_irqrestore+0x42/0x70\n? __pm_runtime_resume+0x7d/0x110\nethnl_set_features+0x32d/0xa20\r\n\r\nTo fix this problem, it uses rhashtable_lookup_fast() instead of\nrhashtable_lookup() with rcu_read_lock().\nUsing xa without rcu_read_lock() here is safe.\nxa is freed by __xdp_mem_allocator_rcu_free() and this is called by\ncall_rcu() of mem_xa_remove().\nThe mem_xa_remove() is called by page_pool_destroy() if a reference\ncount reaches 0.\nThe xa is already protected by the reference count mechanism well in the\ncontrol plane.\nSo removing rcu_read_lock() for page_pool_destroy() is safe.(CVE-2024-43834)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf, arm64: Fix trampoline for BPF_TRAMP_F_CALL_ORIG\r\n\r\nWhen BPF_TRAMP_F_CALL_ORIG is set, the trampoline calls\n__bpf_tramp_enter() and __bpf_tramp_exit() functions, passing them\nthe struct bpf_tramp_image *im pointer as an argument in R0.\r\n\r\nThe trampoline generation code uses emit_addr_mov_i64() to emit\ninstructions for moving the bpf_tramp_image address into R0, but\nemit_addr_mov_i64() assumes the address to be in the vmalloc() space\nand uses only 48 bits. Because bpf_tramp_image is allocated using\nkzalloc(), its address can use more than 48-bits, in this case the\ntrampoline will pass an invalid address to __bpf_tramp_enter/exit()\ncausing a kernel crash.\r\n\r\nFix this by using emit_a64_mov_i64() in place of emit_addr_mov_i64()\nas it can work with addresses that are greater than 48-bits.(CVE-2024-43840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nremoteproc: imx_rproc: Skip over memory region when node value is NULL\r\n\r\nIn imx_rproc_addr_init() \u0026quot;nph = of_count_phandle_with_args()\u0026quot; just counts\nnumber of phandles. But phandles may be empty. So of_parse_phandle() in\nthe parsing loop (0 \u0026lt; a \u0026lt; nph) may return NULL which is later dereferenced.\nAdjust this issue by adding NULL-return check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\r\n\r\n[Fixed title to fit within the prescribed 70-75 charcters](CVE-2024-43860)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmemcg: protect concurrent access to mem_cgroup_idr\r\n\r\nCommit 73f576c04b94 (\u0026quot;mm: memcontrol: fix cgroup creation failure after\nmany small jobs\u0026quot;) decoupled the memcg IDs from the CSS ID space to fix the\ncgroup creation failures.  It introduced IDR to maintain the memcg ID\nspace.  The IDR depends on external synchronization mechanisms for\nmodifications.  For the mem_cgroup_idr, the idr_alloc() and idr_replace()\nhappen within css callback and thus are protected through cgroup_mutex\nfrom concurrent modifications.  However idr_remove() for mem_cgroup_idr\nwas not protected against concurrency and can be run concurrently for\ndifferent memcgs when they hit their refcnt to zero.  Fix that.\r\n\r\nWe have been seeing list_lru based kernel crashes at a low frequency in\nour fleet for a long time.  These crashes were in different part of\nlist_lru code including list_lru_add(), list_lru_del() and reparenting\ncode.  Upon further inspection, it looked like for a given object (dentry\nand inode), the super_block\u0026apos;s list_lru didn\u0026apos;t have list_lru_one for the\nmemcg of that object.  The initial suspicions were either the object is\nnot allocated through kmem_cache_alloc_lru() or somehow\nmemcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but\nreturned success.  No evidence were found for these cases.\r\n\r\nLooking more deeply, we started seeing situations where valid memcg\u0026apos;s id\nis not present in mem_cgroup_idr and in some cases multiple valid memcgs\nhave same id and mem_cgroup_idr is pointing to one of them.  So, the most\nreasonable explanation is that these situations can happen due to race\nbetween multiple idr_remove() calls or race between\nidr_alloc()/idr_replace() and idr_remove().  These races are causing\nmultiple memcgs to acquire the same ID and then offlining of one of them\nwould cleanup list_lrus on the system for all of them.  Later access from\nother memcgs to the list_lru cause crashes due to missing list_lru_one.(CVE-2024-43892)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: core: check uartclk for zero to avoid divide by zero\r\n\r\nCalling ioctl TIOCSSERIAL with an invalid baud_base can\nresult in uartclk being zero, which will result in a\ndivide by zero error in uart_get_divisor(). The check for\nuartclk being zero in uart_set_info() needs to be done\nbefore other settings are made as subsequent calls to\nioctl TIOCSSERIAL for the same port would be impacted if\nthe uartclk check was done where uartclk gets set.\r\n\r\nOops: divide error: 0000  PREEMPT SMP KASAN PTI\nRIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580)\nCall Trace:\n \u0026lt;TASK\u0026gt;\nserial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576\n    drivers/tty/serial/8250/8250_port.c:2589)\nserial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502\n    drivers/tty/serial/8250/8250_port.c:2741)\nserial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862)\nuart_change_line_settings (./include/linux/spinlock.h:376\n    ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222)\nuart_port_startup (drivers/tty/serial/serial_core.c:342)\nuart_startup (drivers/tty/serial/serial_core.c:368)\nuart_set_info (drivers/tty/serial/serial_core.c:1034)\nuart_set_info_user (drivers/tty/serial/serial_core.c:1059)\ntty_set_serial (drivers/tty/tty_io.c:2637)\ntty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791)\n__x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907\n    fs/ioctl.c:893 fs/ioctl.c:893)\ndo_syscall_64 (arch/x86/entry/common.c:52\n    (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\nRule: add(CVE-2024-43893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/client: fix null pointer dereference in drm_client_modeset_probe\r\n\r\nIn drm_client_modeset_probe(), the return value of drm_mode_duplicate() is\nassigned to modeset-\u0026gt;mode, which will lead to a possible NULL pointer\ndereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-43894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngpio: prevent potential speculation leaks in gpio_device_get_desc()\r\n\r\nUserspace may trigger a speculative read of an address outside the gpio\ndescriptor array.\nUsers can do that by calling gpio_ioctl() with an offset out of range.\nOffset is copied from user and then used as an array index to get\nthe gpio descriptor without sanitization in gpio_device_get_desc().\r\n\r\nThis change ensures that the offset is sanitized by using\narray_index_nospec() to mitigate any possibility of speculative\ninformation leaks.\r\n\r\nThis bug was discovered and resolved using Coverity Static Analysis\nSecurity Testing (SAST) by Synopsys, Inc.(CVE-2024-44931)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndriver core: Fix uevent_show() vs driver detach race\r\n\r\nuevent_show() wants to de-reference dev-\u0026gt;driver-\u0026gt;name. There is no clean\nway for a device attribute to de-reference dev-\u0026gt;driver unless that\nattribute is defined via (struct device_driver).dev_groups. Instead, the\nanti-pattern of taking the device_lock() in the attribute handler risks\ndeadlocks with code paths that remove device attributes while holding\nthe lock.\r\n\r\nThis deadlock is typically invisible to lockdep given the device_lock()\nis marked lockdep_set_novalidate_class(), but some subsystems allocate a\nlocal lockdep key for @dev-\u0026gt;mutex to reveal reports of the form:\r\n\r\n ======================================================\n WARNING: possible circular locking dependency detected\n 6.10.0-rc7+ #275 Tainted: G           OE    N\n ------------------------------------------------------\n modprobe/2374 is trying to acquire lock:\n ffff8c2270070de0 (kn-\u0026gt;active#6){++++}-{0:0}, at: __kernfs_remove+0xde/0x220\r\n\r\n but task is already holding lock:\n ffff8c22016e88f8 (\u0026amp;cxl_root_key){+.+.}-{3:3}, at: device_release_driver_internal+0x39/0x210\r\n\r\n which lock already depends on the new lock.\r\n\r\n the existing dependency chain (in reverse order) is:\r\n\r\n -\u0026gt; #1 (\u0026amp;cxl_root_key){+.+.}-{3:3}:\n        __mutex_lock+0x99/0xc30\n        uevent_show+0xac/0x130\n        dev_attr_show+0x18/0x40\n        sysfs_kf_seq_show+0xac/0xf0\n        seq_read_iter+0x110/0x450\n        vfs_read+0x25b/0x340\n        ksys_read+0x67/0xf0\n        do_syscall_64+0x75/0x190\n        entry_SYSCALL_64_after_hwframe+0x76/0x7e\r\n\r\n -\u0026gt; #0 (kn-\u0026gt;active#6){++++}-{0:0}:\n        __lock_acquire+0x121a/0x1fa0\n        lock_acquire+0xd6/0x2e0\n        kernfs_drain+0x1e9/0x200\n        __kernfs_remove+0xde/0x220\n        kernfs_remove_by_name_ns+0x5e/0xa0\n        device_del+0x168/0x410\n        device_unregister+0x13/0x60\n        devres_release_all+0xb8/0x110\n        device_unbind_cleanup+0xe/0x70\n        device_release_driver_internal+0x1c7/0x210\n        driver_detach+0x47/0x90\n        bus_remove_driver+0x6c/0xf0\n        cxl_acpi_exit+0xc/0x11 [cxl_acpi]\n        __do_sys_delete_module.isra.0+0x181/0x260\n        do_syscall_64+0x75/0x190\n        entry_SYSCALL_64_after_hwframe+0x76/0x7e\r\n\r\nThe observation though is that driver objects are typically much longer\nlived than device objects. It is reasonable to perform lockless\nde-reference of a @driver pointer even if it is racing detach from a\ndevice. Given the infrequency of driver unregistration, use\nsynchronize_rcu() in module_remove_driver() to close any potential\nraces.  It is potentially overkill to suffer synchronize_rcu() just to\nhandle the rare module removal racing uevent_show() event.\r\n\r\nThanks to Tetsuo Handa for the debug analysis of the syzbot report [1].(CVE-2024-44952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbonding: fix null pointer deref in bond_ipsec_offload_ok\r\n\r\nWe must check if there is an active slave before dereferencing the pointer.(CVE-2024-44990)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: flowtable: initialise extack before use\r\n\r\nFix missing initialisation of extack in flow offload.(CVE-2024-45018)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: pn533: Add poll mod list filling check\r\n\r\nIn case of im_protocols value is 1 and tm_protocols value is 0 this\ncombination successfully passes the check\n\u0026apos;if (!im_protocols \u0026amp;\u0026amp; !tm_protocols)\u0026apos; in the nfc_start_poll().\nBut then after pn533_poll_create_mod_list() call in pn533_start_poll()\npoll mod list will remain empty and dev-\u0026gt;poll_mod_count will remain 0\nwhich lead to division by zero.\r\n\r\nNormally no im protocol has value 1 in the mask, so this combination is\nnot expected by driver. But these protocol values actually come from\nuserspace via Netlink interface (NFC_CMD_START_POLL operation). So a\nbroken or malicious program may pass a message containing a \u0026quot;bad\u0026quot;\ncombination of protocol parameter values so that dev-\u0026gt;poll_mod_count\nis not incremented inside pn533_poll_create_mod_list(), thus leading\nto division by zero.\nCall trace looks like:\nnfc_genl_start_poll()\n  nfc_start_poll()\n    -\u0026gt;start_poll()\n    pn533_start_poll()\r\n\r\nAdd poll mod list filling check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-46676)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: qcom: cmd-db: Map shared memory as WC, not WB\r\n\r\nLinux does not write into cmd-db region. This region of memory is write\nprotected by XPU. XPU may sometime falsely detect clean cache eviction\nas \u0026quot;write\u0026quot; into the write protected region leading to secure interrupt\nwhich causes an endless loop somewhere in Trust Zone.\r\n\r\nThe only reason it is working right now is because Qualcomm Hypervisor\nmaps the same region as Non-Cacheable memory in Stage 2 translation\ntables. The issue manifests if we want to use another hypervisor (like\nXen or KVM), which does not know anything about those specific mappings.\r\n\r\nChanging the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC\nremoves dependency on correct mappings in Stage 2 tables. This patch\nfixes the issue by updating the mapping to MEMREMAP_WC.\r\n\r\nI tested this on SA8155P with Xen.(CVE-2024-46689)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: typec: ucsi: Move unregister out of atomic section\r\n\r\nCommit \u0026apos;9329933699b3 (\u0026quot;soc: qcom: pmic_glink: Make client-lock\nnon-sleeping\u0026quot;)\u0026apos; moved the pmic_glink client list under a spinlock, as it\nis accessed by the rpmsg/glink callback, which in turn is invoked from\nIRQ context.\r\n\r\nThis means that ucsi_unregister() is now called from atomic context,\nwhich isn\u0026apos;t feasible as it\u0026apos;s expecting a sleepable context. An effort is\nunder way to get GLINK to invoke its callbacks in a sleepable context,\nbut until then lets schedule the unregistration.\r\n\r\nA side effect of this is that ucsi_unregister() can now happen\nafter the remote processor, and thereby the communication link with it, is\ngone. pmic_glink_send() is amended with a check to avoid the resulting NULL\npointer dereference.\nThis does however result in the user being informed about this error by\nthe following entry in the kernel log:\r\n\r\n  ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: failed to send UCSI write request: -5(CVE-2024-46691)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vmwgfx: Fix prime with external buffers\r\n\r\nMake sure that for external buffers mapping goes through the dma_buf\ninterface instead of trying to access pages directly.\r\n\r\nExternal buffers might not provide direct access to readable/writable\npages so to make sure the bo\u0026apos;s created from external dma_bufs can be\nread dma_buf interface has to be used.\r\n\r\nFixes crashes in IGT\u0026apos;s kms_prime with vgem. Regular desktop usage won\u0026apos;t\ntrigger this due to the fact that virtual machines will not have\nmultiple GPUs but it enables better test coverage in IGT.(CVE-2024-46709)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndmaengine: altera-msgdma: properly free descriptor in msgdma_free_descriptor\r\n\r\nRemove list_del call in msgdma_chan_desc_cleanup, this should be the role\nof msgdma_free_descriptor. In consequence replace list_add_tail with\nlist_move_tail in msgdma_free_descriptor.\r\n\r\nThis fixes the path:\n   msgdma_free_chan_resources -\u0026gt; msgdma_free_descriptors -\u0026gt;\n   msgdma_free_desc_list -\u0026gt; msgdma_free_descriptor\r\n\r\nwhich does not correctly free the descriptors as first nodes were not\nremoved from the list.(CVE-2024-46716)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Ensure index calculation will not overflow\r\n\r\n[WHY \u0026amp; HOW]\nMake sure vmid0p72_idx, vnom0p8_idx and vmax0p9_idx calculation will\nnever overflow and exceess array size.\r\n\r\nThis fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-46726)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Remove tst_run from lwt_seg6local_prog_ops.\r\n\r\nThe syzbot reported that the lwt_seg6 related BPF ops can be invoked\nvia bpf_test_run() without without entering input_action_end_bpf()\nfirst.\r\n\r\nMartin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCAL\nprobably didn\u0026apos;t work since it was introduced in commit 04d4b274e2a\n(\u0026quot;ipv6: sr: Add seg6local action End.BPF\u0026quot;). The reason is that the\nper-CPU variable seg6_bpf_srh_states::srh is never assigned in the self\ntest case but each BPF function expects it.\r\n\r\nRemove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.(CVE-2024-46754)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: unset the binding mark of a reused connection\r\n\r\nSteve French reported null pointer dereference error from sha256 lib.\ncifs.ko can send session setup requests on reused connection.\nIf reused connection is used for binding session, conn-\u0026gt;binding can\nstill remain true and generate_preauth_hash() will not set\nsess-\u0026gt;Preauth_HashValue and it will be NULL.\nIt is used as a material to create an encryption key in\nksmbd_gen_smb311_encryptionkey. -\u0026gt;Preauth_HashValue cause null pointer\ndereference error from crypto_shash_update().\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n#PF: supervisor read access in kernel mode\n#PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 8 PID: 429254 Comm: kworker/8:39\nHardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 )\nWorkqueue: ksmbd-io handle_ksmbd_work [ksmbd]\nRIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]\n\u0026lt;TASK\u0026gt;\n? show_regs+0x6d/0x80\n? __die+0x24/0x80\n? page_fault_oops+0x99/0x1b0\n? do_user_addr_fault+0x2ee/0x6b0\n? exc_page_fault+0x83/0x1b0\n? asm_exc_page_fault+0x27/0x30\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n_sha256_update+0x77/0xa0 [sha256_ssse3]\nsha256_avx2_update+0x15/0x30 [sha256_ssse3]\ncrypto_shash_update+0x1e/0x40\nhmac_update+0x12/0x20\ncrypto_shash_update+0x1e/0x40\ngenerate_key+0x234/0x380 [ksmbd]\ngenerate_smb3encryptionkey+0x40/0x1c0 [ksmbd]\nksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd]\nntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd]\nsmb2_sess_setup+0x952/0xaa0 [ksmbd]\n__process_request+0xa3/0x1d0 [ksmbd]\n__handle_ksmbd_work+0x1c4/0x2f0 [ksmbd]\nhandle_ksmbd_work+0x2d/0xa0 [ksmbd]\nprocess_one_work+0x16c/0x350\nworker_thread+0x306/0x440\n? __pfx_worker_thread+0x10/0x10\nkthread+0xef/0x120\n? __pfx_kthread+0x10/0x10\nret_from_fork+0x44/0x70\n? __pfx_kthread+0x10/0x10\nret_from_fork_asm+0x1b/0x30\n\u0026lt;/TASK\u0026gt;(CVE-2024-46795)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix the waring dereferencing hive\r\n\r\nCheck the amdgpu_hive_info *hive that maybe is NULL.(CVE-2024-46805)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/bridge: tc358767: Check if fully initialized before signalling HPD event via IRQ\r\n\r\nMake sure the connector is fully initialized before signalling any\nHPD events via drm_kms_helper_hotplug_event(), otherwise this may\nlead to NULL pointer dereference.(CVE-2024-46810)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6\r\n\r\n[Why]\nCoverity reports OVERRUN warning. Should abort amdgpu_dm\ninitialize.\r\n\r\n[How]\nReturn failure to amdgpu_dm_init.(CVE-2024-46817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: the warning dereferencing obj for nbio_v7_4\r\n\r\nif ras_manager obj null, don\u0026apos;t print NBIO err data(CVE-2024-46819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: Fix negative array index read\r\n\r\nAvoid using the negative values\nfor clk_idex as an index into an array pptable-\u0026gt;DpmDescriptor.\r\n\r\nV2: fix clk_index return check (Tim Huang)(CVE-2024-46821)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\narm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry\r\n\r\nIn a review discussion of the changes to support vCPU hotplug where\na check was added on the GICC being enabled if was online, it was\nnoted that there is need to map back to the cpu and use that to index\ninto a cpumask. As such, a valid ID is needed.\r\n\r\nIf an MPIDR check fails in acpi_map_gic_cpu_interface() it is possible\nfor the entry in cpu_madt_gicc[cpu] == NULL.  This function would\nthen cause a NULL pointer dereference.   Whilst a path to trigger\nthis has not been established, harden this caller against the\npossibility.(CVE-2024-46822)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nELF: fix kernel.randomize_va_space double read\r\n\r\nELF loader uses \u0026quot;randomize_va_space\u0026quot; twice. It is sysctl and can change\nat any moment, so 2 loads could see 2 different values in theory with\nunpredictable consequences.\r\n\r\nIssue exactly one load for consistent value across one exec.(CVE-2024-46826)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: x86: Acquire kvm-\u0026gt;srcu when handling KVM_SET_VCPU_EVENTS\r\n\r\nGrab kvm-\u0026gt;srcu when processing KVM_SET_VCPU_EVENTS, as KVM will forcibly\nleave nested VMX/SVM if SMM mode is being toggled, and leaving nested VMX\nreads guest memory.\r\n\r\nNote, kvm_vcpu_ioctl_x86_set_vcpu_events() can also be called from KVM_RUN\nvia sync_regs(), which already holds SRCU.  I.e. trying to precisely use\nkvm_vcpu_srcu_read_lock() around the problematic SMM code would cause\nproblems.  Acquiring SRCU isn\u0026apos;t all that expensive, so for simplicity,\ngrab it unconditionally for KVM_SET_VCPU_EVENTS.\r\n\r\n =============================\n WARNING: suspicious RCU usage\n 6.10.0-rc7-332d2c1d713e-next-vm #552 Not tainted\n -----------------------------\n include/linux/kvm_host.h:1027 suspicious rcu_dereference_check() usage!\r\n\r\n other info that might help us debug this:\r\n\r\n rcu_scheduler_active = 2, debug_locks = 1\n 1 lock held by repro/1071:\n  #0: ffff88811e424430 (\u0026amp;vcpu-\u0026gt;mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x7d/0x970 [kvm]\r\n\r\n stack backtrace:\n CPU: 15 PID: 1071 Comm: repro Not tainted 6.10.0-rc7-332d2c1d713e-next-vm #552\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  dump_stack_lvl+0x7f/0x90\n  lockdep_rcu_suspicious+0x13f/0x1a0\n  kvm_vcpu_gfn_to_memslot+0x168/0x190 [kvm]\n  kvm_vcpu_read_guest+0x3e/0x90 [kvm]\n  nested_vmx_load_msr+0x6b/0x1d0 [kvm_intel]\n  load_vmcs12_host_state+0x432/0xb40 [kvm_intel]\n  vmx_leave_nested+0x30/0x40 [kvm_intel]\n  kvm_vcpu_ioctl_x86_set_vcpu_events+0x15d/0x2b0 [kvm]\n  kvm_arch_vcpu_ioctl+0x1107/0x1750 [kvm]\n  ? mark_held_locks+0x49/0x70\n  ? kvm_vcpu_ioctl+0x7d/0x970 [kvm]\n  ? kvm_vcpu_ioctl+0x497/0x970 [kvm]\n  kvm_vcpu_ioctl+0x497/0x970 [kvm]\n  ? lock_acquire+0xba/0x2d0\n  ? find_held_lock+0x2b/0x80\n  ? do_user_addr_fault+0x40c/0x6f0\n  ? lock_release+0xb7/0x270\n  __x64_sys_ioctl+0x82/0xb0\n  do_syscall_64+0x6c/0x170\n  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7ff11eb1b539\n  \u0026lt;/TASK\u0026gt;(CVE-2024-46830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: aspeed_udc: validate endpoint index for ast udc\r\n\r\nWe should verify the bound of the array to assure that host\nmay not manipulate the index to point past endpoint array.\r\n\r\nFound by static analysis.(CVE-2024-46836)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nuserfaultfd: don\u0026apos;t BUG_ON() if khugepaged yanks our page table\r\n\r\nSince khugepaged was changed to allow retracting page tables in file\nmappings without holding the mmap lock, these BUG_ON()s are wrong - get\nrid of them.\r\n\r\nWe could also remove the preceding \u0026quot;if (unlikely(...))\u0026quot; block, but then we\ncould reach pte_offset_map_lock() with transhuge pages not just for file\nmappings but also for anonymous mappings - which would probably be fine\nbut I think is not necessarily expected.(CVE-2024-46838)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: clean up our handling of refs == 0 in snapshot delete\r\n\r\nIn reada we BUG_ON(refs == 0), which could be unkind since we aren\u0026apos;t\nholding a lock on the extent leaf and thus could get a transient\nincorrect answer.  In walk_down_proc we also BUG_ON(refs == 0), which\ncould happen if we have extent tree corruption.  Change that to return\n-EUCLEAN.  In do_walk_down() we catch this case and handle it correctly,\nhowever we return -EIO, which -EUCLEAN is a more appropriate error code.\nFinally in walk_up_proc we have the same BUG_ON(refs == 0), so convert\nthat to proper error handling.  Also adjust the error message so we can\nactually do something with the information.(CVE-2024-46840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: dpaa: Pad packets to ETH_ZLEN\r\n\r\nWhen sending packets under 60 bytes, up to three bytes of the buffer\nfollowing the data may be leaked. Avoid this by extending all packets to\nETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be\nreproduced by running\r\n\r\n\t$ ping -s 11 destination(CVE-2024-46854)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_socket: fix sk refcount leaks\r\n\r\nWe must put \u0026apos;sk\u0026apos; reference before returning.(CVE-2024-46855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmptcp: pm: Fix uaf in __timer_delete_sync\r\n\r\nThere are two paths to access mptcp_pm_del_add_timer, result in a race\ncondition:\r\n\r\n     CPU1\t\t\t\tCPU2\n     ====                               ====\n     net_rx_action\n     napi_poll                          netlink_sendmsg\n     __napi_poll                        netlink_unicast\n     process_backlog                    netlink_unicast_kernel\n     __netif_receive_skb                genl_rcv\n     __netif_receive_skb_one_core       netlink_rcv_skb\n     NF_HOOK                            genl_rcv_msg\n     ip_local_deliver_finish            genl_family_rcv_msg\n     ip_protocol_deliver_rcu            genl_family_rcv_msg_doit\n     tcp_v4_rcv                         mptcp_pm_nl_flush_addrs_doit\n     tcp_v4_do_rcv                      mptcp_nl_remove_addrs_list\n     tcp_rcv_established                mptcp_pm_remove_addrs_and_subflows\n     tcp_data_queue                     remove_anno_list_by_saddr\n     mptcp_incoming_options             mptcp_pm_del_add_timer\n     mptcp_pm_del_add_timer             kfree(entry)\r\n\r\nIn remove_anno_list_by_saddr(running on CPU2), after leaving the critical\nzone protected by \u0026quot;pm.lock\u0026quot;, the entry will be released, which leads to the\noccurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).\r\n\r\nKeeping a reference to add_timer inside the lock, and calling\nsk_stop_timer_sync() with this reference, instead of \u0026quot;entry-\u0026gt;add_timer\u0026quot;.\r\n\r\nMove list_del(\u0026amp;entry-\u0026gt;list) to mptcp_pm_del_add_timer and inside the pm lock,\ndo not directly access any members of the entry outside the pm lock, which\ncan avoid similar \u0026quot;entry-\u0026gt;x\u0026quot; uaf.(CVE-2024-46858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nplatform/x86: panasonic-laptop: Fix SINF array out of bounds accesses\r\n\r\nThe panasonic laptop code in various places uses the SINF array with index\nvalues of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF array\nis big enough.\r\n\r\nNot all panasonic laptops have this many SINF array entries, for example\nthe Toughbook CF-18 model only has 10 SINF array entries. So it only\nsupports the AC+DC brightness entries and mute.\r\n\r\nCheck that the SINF array has a minimum size which covers all AC+DC\nbrightness entries and refuse to load if the SINF array is smaller.\r\n\r\nFor higher SINF indexes hide the sysfs attributes when the SINF array\ndoes not contain an entry for that attribute, avoiding show()/store()\naccessing the array out of bounds and add bounds checking to the probe()\nand resume() code accessing these.(CVE-2024-46859)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: stm32/cryp - call finalize with bh disabled\r\n\r\nThe finalize operation in interrupt mode produce a produces a spinlock\nrecursion warning. The reason is the fact that BH must be disabled\nduring this process.(CVE-2024-47658)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA setup\r\n\r\nDefinitely condition dma_get_cache_alignment * defined value \u0026gt; 256\nduring driver initialization is not reason to BUG_ON(). Turn that to\ngraceful error out with -EINVAL.(CVE-2024-47665)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix state management in error path of log writing function\r\n\r\nAfter commit a694291a6211 (\u0026quot;nilfs2: separate wait function from\nnilfs_segctor_write\u0026quot;) was applied, the log writing function\nnilfs_segctor_do_construct() was able to issue I/O requests continuously\neven if user data blocks were split into multiple logs across segments,\nbut two potential flaws were introduced in its error handling.\r\n\r\nFirst, if nilfs_segctor_begin_construction() fails while creating the\nsecond or subsequent logs, the log writing function returns without\ncalling nilfs_segctor_abort_construction(), so the writeback flag set on\npages/folios will remain uncleared.  This causes page cache operations to\nhang waiting for the writeback flag.  For example,\ntruncate_inode_pages_final(), which is called via nilfs_evict_inode() when\nan inode is evicted from memory, will hang.\r\n\r\nSecond, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. \nAs a result, if the next log write involves checkpoint creation, that\u0026apos;s\nfine, but if a partial log write is performed that does not, inodes with\nNILFS_I_COLLECTED set are erroneously removed from the \u0026quot;sc_dirty_files\u0026quot;\nlist, and their data and b-tree blocks may not be written to the device,\ncorrupting the block mapping.\r\n\r\nFix these issues by uniformly calling nilfs_segctor_abort_construction()\non failure of each step in the loop in nilfs_segctor_do_construct(),\nhaving it clean up logs and segment usages according to progress, and\ncorrecting the conditions for calling nilfs_redirty_inodes() to ensure\nthat the NILFS_I_COLLECTED flag is cleared.(CVE-2024-47669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: usbtmc: prevent kernel-usb-infoleak\r\n\r\nThe syzbot reported a kernel-usb-infoleak in usbtmc_write,\nwe need to clear the structure before filling fields.(CVE-2024-47671)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: mvm: don\u0026apos;t wait for tx queues if firmware is dead\r\n\r\nThere is a WARNING in iwl_trans_wait_tx_queues_empty() (that was\nrecently converted from just a message), that can be hit if we\nwait for TX queues to become empty after firmware died. Clearly,\nwe can\u0026apos;t expect anything from the firmware after it\u0026apos;s declared dead.\r\n\r\nDon\u0026apos;t call iwl_trans_wait_tx_queues_empty() in this case. While it could\nbe a good idea to stop the flow earlier, the flush functions do some\nmaintenance work that is not related to the firmware, so keep that part\nof the code running even when the firmware is not running.\r\n\r\n[edit commit message](CVE-2024-47672)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()  If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe\u0026apos;s without calling bpf_uprobe_unregister().  This leaks bpf_uprobe-\u0026gt;uprobe and worse, this frees bpf_uprobe-\u0026gt;consumer without removing it from the uprobe-\u0026gt;consumers list.(CVE-2024-47675)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drivers/perf: Fix ali_drw_pmu driver interrupt status clearing  The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang.  Therefore, clear the correct interrupt status in the interrupt handling function to fix it.(CVE-2024-47731)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: fix race setting file private on concurrent lseek using same fd  When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak.  The race happens like this:  1) A program opens a file descriptor for a file and then spawns two    threads (with the pthreads library for example), lets call them    task A and task B;  2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at    file.c:find_desired_extent() while holding a read lock on the inode;  3) At the start of find_desired_extent(), it extracts the file\u0026apos;s    private_data pointer into a local variable named \u0026apos;private\u0026apos;, which has    a value of NULL;  4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode    in shared mode and enters file.c:find_desired_extent(), where it also    extracts file-\u0026gt;private_data into its local variable \u0026apos;private\u0026apos;, which    has a NULL value;  5) Because it saw a NULL file private, task A allocates a private    structure and assigns to the file structure;  6) Task B also saw a NULL file private so it also allocates its own file    private and then assigns it to the same file structure, since both    tasks are using the same file descriptor.     At this point we leak the private structure allocated by task A.  Besides the memory leak, there\u0026apos;s also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state.  Fix this by protecting the private assignment and check of a file while holding the inode\u0026apos;s spinlock and keep track of the task that allocated the private, so that it\u0026apos;s used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.(CVE-2024-47741)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-47.0.0.52.oe2403"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-47.0.0.52.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-47.0.0.52.oe2403.aarch64.rpm","kernel-6.6.0-47.0.0.52.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-47.0.0.52.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-47.0.0.52.oe2403.aarch64.rpm","kernel-devel-6.6.0-47.0.0.52.oe2403.aarch64.rpm","kernel-headers-6.6.0-47.0.0.52.oe2403.aarch64.rpm","kernel-source-6.6.0-47.0.0.52.oe2403.aarch64.rpm","kernel-tools-6.6.0-47.0.0.52.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-47.0.0.52.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-47.0.0.52.oe2403.aarch64.rpm","perf-6.6.0-47.0.0.52.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-47.0.0.52.oe2403.aarch64.rpm","python3-perf-6.6.0-47.0.0.52.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-47.0.0.52.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-47.0.0.52.oe2403.src.rpm"],"x86_64":["bpftool-6.6.0-47.0.0.52.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-47.0.0.52.oe2403.x86_64.rpm","kernel-6.6.0-47.0.0.52.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-47.0.0.52.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-47.0.0.52.oe2403.x86_64.rpm","kernel-devel-6.6.0-47.0.0.52.oe2403.x86_64.rpm","kernel-headers-6.6.0-47.0.0.52.oe2403.x86_64.rpm","kernel-source-6.6.0-47.0.0.52.oe2403.x86_64.rpm","kernel-tools-6.6.0-47.0.0.52.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-47.0.0.52.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-47.0.0.52.oe2403.x86_64.rpm","perf-6.6.0-47.0.0.52.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-47.0.0.52.oe2403.x86_64.rpm","python3-perf-6.6.0-47.0.0.52.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-47.0.0.52.oe2403.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2296"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52889"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27397"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36012"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36015"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36032"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36244"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36880"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36889"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36894"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36909"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36910"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36911"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36913"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36915"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36918"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36920"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36921"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36922"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36927"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36936"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36940"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36941"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36946"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36963"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36971"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38594"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38608"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38612"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40999"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42104"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42128"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42157"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42229"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42232"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42236"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42280"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42283"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42286"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42287"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42289"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42290"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42292"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42295"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42299"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42305"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42306"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42308"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42309"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42311"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42313"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42322"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43823"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43828"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43830"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43831"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43834"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43840"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43860"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43892"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43893"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43894"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44931"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44952"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44990"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45018"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46676"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46689"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46691"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46709"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46716"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46726"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46754"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46795"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46805"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46810"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46817"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46819"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46821"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46822"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46826"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46830"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46836"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46838"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46840"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46854"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46855"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46858"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46859"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47658"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47665"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47669"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47671"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47672"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47675"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47731"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47741"}],"database_specific":{"severity":"Critical"}}