{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "kernel-debuginfo-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "kernel-debugsource-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "kernel-devel-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "kernel-headers-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "kernel-source-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "kernel-tools-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "kernel-tools-devel-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "perf-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "perf-debuginfo-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "python3-perf-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-136.96.0.177.oe2203sp1.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "kernel-debuginfo-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "kernel-debugsource-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "kernel-devel-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "kernel-headers-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "kernel-source-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "kernel-tools-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "kernel-tools-devel-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "perf-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "perf-debuginfo-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "python3-perf-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP1",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-136.96.0.177.oe2203sp1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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\nALSA: usb-audio: Stop parsing channels bits when all channels are found.\r\n\r\nIf a usb audio device sets more bits than the amount of channels\nit could write outside of the map array.(CVE-2024-27436)\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\nscsi: bfa: Ensure the copied buf is NUL terminated\r\n\r\nCurrently, we allocate a nbytes-sized kernel buffer and copy nbytes from\nuserspace to that buffer. Later, we use sscanf on this buffer but we don\u0026apos;t\nensure that the string is terminated inside the buffer, this can lead to\nOOB read when using sscanf. Fix this issue by using memdup_user_nul instead\nof memdup_user.(CVE-2024-38560)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nenic: Validate length of nl attributes in enic_set_vf_port\r\n\r\nenic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILE\nis of length PORT_PROFILE_MAX and that the nl attributes\nIFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX.\nThese attributes are validated (in the function do_setlink in rtnetlink.c)\nusing the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILE\nas NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY and\nIFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validation\nusing the policy is for the max size of the attributes and not on exact\nsize so the length of these attributes might be less than the sizes that\nenic_set_vf_port expects. This might cause an out of bands\nread access in the memcpys of the data of these\nattributes in enic_set_vf_port.(CVE-2024-38659)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbcache: fix variable length array abuse in btree_iter\r\n\r\nbtree_iter is used in two ways: either allocated on the stack with a\nfixed size MAX_BSETS, or from a mempool with a dynamic size based on the\nspecific cache set. Previously, the struct had a fixed-length array of\nsize MAX_BSETS which was indexed out-of-bounds for the dynamically-sized\niterators, which causes UBSAN to complain.\r\n\r\nThis patch uses the same approach as in bcachefs\u0026apos;s sort_iter and splits\nthe iterator into a btree_iter with a flexible array member and a\nbtree_iter_stack which embeds a btree_iter as well as a fixed-length\ndata array.(CVE-2024-39482)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers: core: synchronize really_probe() and dev_uevent()\r\n\r\nSynchronize the dev-\u0026gt;driver usage in really_probe() and dev_uevent().\nThese can run in different threads, what can result in the following\nrace condition for dev-\u0026gt;driver uninitialization:\r\n\r\nThread #1:\n==========\r\n\r\nreally_probe() {\n...\nprobe_failed:\n...\ndevice_unbind_cleanup(dev) {\n    ...\n    dev-\u0026gt;driver = NULL;   // \u0026lt;= Failed probe sets dev-\u0026gt;driver to NULL\n    ...\n    }\n...\n}\r\n\r\nThread #2:\n==========\r\n\r\ndev_uevent() {\n...\nif (dev-\u0026gt;driver)\n      // If dev-\u0026gt;driver is NULLed from really_probe() from here on,\n      // after above check, the system crashes\n      add_uevent_var(env, \u0026quot;DRIVER=%s\u0026quot;, dev-\u0026gt;driver-\u0026gt;name);\n...\n}\r\n\r\nreally_probe() holds the lock, already. So nothing needs to be done\nthere. dev_uevent() is called with lock held, often, too. But not\nalways. What implies that we can\u0026apos;t add any locking in dev_uevent()\nitself. So fix this race by adding the lock to the non-protected\npath. This is the path where above race is observed:\r\n\r\n dev_uevent+0x235/0x380\n uevent_show+0x10c/0x1f0  \u0026lt;= Add lock here\n dev_attr_show+0x3a/0xa0\n sysfs_kf_seq_show+0x17c/0x250\n kernfs_seq_show+0x7c/0x90\n seq_read_iter+0x2d7/0x940\n kernfs_fop_read_iter+0xc6/0x310\n vfs_read+0x5bc/0x6b0\n ksys_read+0xeb/0x1b0\n __x64_sys_read+0x42/0x50\n x64_sys_call+0x27ad/0x2d30\n do_syscall_64+0xcd/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nSimilar cases are reported by syzkaller in\r\n\r\nhttps://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a\r\n\r\nBut these are regarding the *initialization* of dev-\u0026gt;driver\r\n\r\ndev-\u0026gt;driver = drv;\r\n\r\nAs this switches dev-\u0026gt;driver to non-NULL these reports can be considered\nto be false-positives (which should be \u0026quot;fixed\u0026quot; by this commit, as well,\nthough).\r\n\r\nThe same issue was reported and tried to be fixed back in 2015 in\r\n\r\nhttps://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/\r\n\r\nalready.(CVE-2024-39501)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qedi: Fix crash while reading debugfs attribute\r\n\r\nThe qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly\non a __user pointer, which results into the crash.\r\n\r\nTo fix this issue, use a small local stack buffer for sprintf() and then\ncall simple_read_from_buffer(), which in turns make the copy_to_user()\ncall.\r\n\r\nBUG: unable to handle page fault for address: 00007f4801111000\nPGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0\nOops: 0002 [#1] PREEMPT SMP PTI\nHardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023\nRIP: 0010:memcpy_orig+0xcd/0x130\nRSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202\nRAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f\nRDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000\nRBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572\nR10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff\nR13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af\nFS:  00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x183/0x510\n ? exc_page_fault+0x69/0x150\n ? asm_exc_page_fault+0x22/0x30\n ? memcpy_orig+0xcd/0x130\n vsnprintf+0x102/0x4c0\n sprintf+0x51/0x80\n qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]\n full_proxy_read+0x50/0x80\n vfs_read+0xa5/0x2e0\n ? folio_add_new_anon_rmap+0x44/0xa0\n ? set_pte_at+0x15/0x30\n ? do_pte_missing+0x426/0x7f0\n ksys_read+0xa5/0xe0\n do_syscall_64+0x58/0x80\n ? __count_memcg_events+0x46/0x90\n ? count_memcg_event_mm+0x3d/0x60\n ? handle_mm_fault+0x196/0x2f0\n ? do_user_addr_fault+0x267/0x890\n ? exc_page_fault+0x69/0x150\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7f4800f20b4d(CVE-2024-40978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: discard write access to the directory open\r\n\r\nmay_open() does not allow a directory to be opened with the write access.\nHowever, some writing flags set by client result in adding write access\non server, making ksmbd incompatible with FUSE file system. Simply, let\u0026apos;s\ndiscard the write access when opening a directory.\r\n\r\nlist_add corruption. next is NULL.\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:26!\npc : __list_add_valid+0x88/0xbc\nlr : __list_add_valid+0x88/0xbc\nCall trace:\n__list_add_valid+0x88/0xbc\nfuse_finish_open+0x11c/0x170\nfuse_open_common+0x284/0x5e8\nfuse_dir_open+0x14/0x24\ndo_dentry_open+0x2a4/0x4e0\ndentry_open+0x50/0x80\nsmb2_open+0xbe4/0x15a4\nhandle_ksmbd_work+0x478/0x5ec\nprocess_one_work+0x1b4/0x448\nworker_thread+0x25c/0x430\nkthread+0x104/0x1d4\nret_from_fork+0x10/0x20(CVE-2024-41030)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes\r\n\r\nIn nv17_tv_get_ld_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-41095)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlib: objagg: Fix general protection fault\r\n\r\nThe library supports aggregation of objects into other objects only if\nthe parent object does not have a parent itself. That is, nesting is not\nsupported.\r\n\r\nAggregation happens in two cases: Without and with hints, where hints\nare a pre-computed recommendation on how to aggregate the provided\nobjects.\r\n\r\nNesting is not possible in the first case due to a check that prevents\nit, but in the second case there is no check because the assumption is\nthat nesting cannot happen when creating objects based on hints. The\nviolation of this assumption leads to various warnings and eventually to\na general protection fault [1].\r\n\r\nBefore fixing the root cause, error out when nesting happens and warn.\r\n\r\n[1]\ngeneral protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI\nCPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G        W          6.9.0-rc6-custom-gd9b4f1cca7fb #7\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlxsw_sp_acl_atcam_entry_add+0x256/0x3c0\n mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0\n mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270\n mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510\n process_one_work+0x151/0x370\n worker_thread+0x2cb/0x3e0\n kthread+0xd0/0x100\n ret_from_fork+0x34/0x50\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2024-43846)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vmwgfx: Fix a deadlock in dma buf fence polling\r\n\r\nIntroduce a version of the fence ops that on release doesn\u0026apos;t remove\nthe fence from the pending list, and thus doesn\u0026apos;t require a lock to\nfix poll-\u0026gt;fence wait-\u0026gt;fence unref deadlocks.\r\n\r\nvmwgfx overwrites the wait callback to iterate over the list of all\nfences and update their status, to do that it holds a lock to prevent\nthe list modifcations from other threads. The fence destroy callback\nboth deletes the fence and removes it from the list of pending\nfences, for which it holds a lock.\r\n\r\ndma buf polling cb unrefs a fence after it\u0026apos;s been signaled: so the poll\ncalls the wait, which signals the fences, which are being destroyed.\nThe destruction tries to acquire the lock on the pending fences list\nwhich it can never get because it\u0026apos;s held by the wait from which it\nwas called.\r\n\r\nOld bug, but not a lot of userspace apps were using dma-buf polling\ninterfaces. Fix those, in particular this fixes KDE stalls/deadlock.(CVE-2024-43863)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: xc2028: avoid use-after-free in load_firmware_cb()\r\n\r\nsyzkaller reported use-after-free in load_firmware_cb() [1].\nThe reason is because the module allocated a struct tuner in tuner_probe(),\nand then the module initialization failed, the struct tuner was released.\nA worker which created during module initialization accesses this struct\ntuner later, it caused use-after-free.\r\n\r\nThe process is as follows:\r\n\r\ntask-6504           worker_thread\ntuner_probe                             \u0026lt;= alloc dvb_frontend [2]\n...\nrequest_firmware_nowait                 \u0026lt;= create a worker\n...\ntuner_remove                            \u0026lt;= free dvb_frontend\n...\n                    request_firmware_work_func  \u0026lt;= the firmware is ready\n                    load_firmware_cb    \u0026lt;= but now the dvb_frontend has been freed\r\n\r\nTo fix the issue, check the dvd_frontend in load_firmware_cb(), if it is\nnull, report a warning and just return.\r\n\r\n[1]:\n    ==================================================================\n     BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0\n     Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504\r\n\r\n     Call trace:\n      load_firmware_cb+0x1310/0x17a0\n      request_firmware_work_func+0x128/0x220\n      process_one_work+0x770/0x1824\n      worker_thread+0x488/0xea0\n      kthread+0x300/0x430\n      ret_from_fork+0x10/0x20\r\n\r\n     Allocated by task 6504:\n      kzalloc\n      tuner_probe+0xb0/0x1430\n      i2c_device_probe+0x92c/0xaf0\n      really_probe+0x678/0xcd0\n      driver_probe_device+0x280/0x370\n      __device_attach_driver+0x220/0x330\n      bus_for_each_drv+0x134/0x1c0\n      __device_attach+0x1f4/0x410\n      device_initial_probe+0x20/0x30\n      bus_probe_device+0x184/0x200\n      device_add+0x924/0x12c0\n      device_register+0x24/0x30\n      i2c_new_device+0x4e0/0xc44\n      v4l2_i2c_new_subdev_board+0xbc/0x290\n      v4l2_i2c_new_subdev+0xc8/0x104\n      em28xx_v4l2_init+0x1dd0/0x3770\r\n\r\n     Freed by task 6504:\n      kfree+0x238/0x4e4\n      tuner_remove+0x144/0x1c0\n      i2c_device_remove+0xc8/0x290\n      __device_release_driver+0x314/0x5fc\n      device_release_driver+0x30/0x44\n      bus_remove_device+0x244/0x490\n      device_del+0x350/0x900\n      device_unregister+0x28/0xd0\n      i2c_unregister_device+0x174/0x1d0\n      v4l2_device_unregister+0x224/0x380\n      em28xx_v4l2_init+0x1d90/0x3770\r\n\r\n     The buggy address belongs to the object at ffff8000d7ca2000\n      which belongs to the cache kmalloc-2k of size 2048\n     The buggy address is located 776 bytes inside of\n      2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)\n     The buggy address belongs to the page:\n     page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0\n     flags: 0x7ff800000000100(slab)\n     raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000\n     raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000\n     page dumped because: kasan: bad access detected\r\n\r\n     Memory state around the buggy address:\n      ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n      ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     \u0026gt;ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                           ^\n      ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n      ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     ==================================================================\r\n\r\n[2]\n    Actually, it is allocated for struct tuner, and dvb_frontend is inside.(CVE-2024-43900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix null ptr deref in dtInsertEntry\r\n\r\n[syzbot reported]\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nRIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713\n...\n[Analyze]\nIn dtInsertEntry(), when the pointer h has the same value as p, after writing\nname in UniStrncpy_to_le(), p-\u0026gt;header.flag will be cleared. This will cause the\npreviously true judgment \u0026quot;p-\u0026gt;header.flag \u0026amp; BT-LEAF\u0026quot; to change to no after writing\nthe name operation, this leads to entering an incorrect branch and accessing the\nuninitialized object ih when judging this condition for the second time.\r\n\r\n[Fix]\nAfter got the page, check freelist first, if freelist == 0 then exit dtInsert()\nand return -EINVAL.(CVE-2024-44939)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: line6: Fix racy access to midibuf\r\n\r\nThere can be concurrent accesses to line6 midibuf from both the URB\ncompletion callback and the rawmidi API access.  This could be a cause\nof KMSAN warning triggered by syzkaller below (so put as reported-by\nhere).\r\n\r\nThis patch protects the midibuf call of the former code path with a\nspinlock for avoiding the possible races.(CVE-2024-44954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched/smt: Fix unbalance sched_smt_present dec/inc\r\n\r\nI got the following warn report while doing stress test:\r\n\r\njump label: negative count!\nWARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __static_key_slow_dec_cpuslocked+0x16/0x70\n sched_cpu_deactivate+0x26e/0x2a0\n cpuhp_invoke_callback+0x3ad/0x10d0\n cpuhp_thread_fun+0x3f5/0x680\n smpboot_thread_fn+0x56d/0x8d0\n kthread+0x309/0x400\n ret_from_fork+0x41/0x70\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nBecause when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),\nthe cpu offline failed, but sched_smt_present is decremented before\ncalling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so\nfix it by incrementing sched_smt_present in the error path.(CVE-2024-44958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/msm/dpu: cleanup FB if dpu_format_populate_layout fails\r\n\r\nIf the dpu_format_populate_layout() fails, then FB is prepared, but not\ncleaned up. This ends up leaking the pin_count on the GEM object and\ncauses a splat during DRM file closure:\r\n\r\nmsm_obj-\u0026gt;pin_count\nWARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc\n[...]\nCall trace:\n update_lru_locked+0xc4/0xcc\n put_pages+0xac/0x100\n msm_gem_free_object+0x138/0x180\n drm_gem_object_free+0x1c/0x30\n drm_gem_object_handle_put_unlocked+0x108/0x10c\n drm_gem_object_release_handle+0x58/0x70\n idr_for_each+0x68/0xec\n drm_gem_release+0x28/0x40\n drm_file_free+0x174/0x234\n drm_release+0xb0/0x160\n __fput+0xc0/0x2c8\n __fput_sync+0x50/0x5c\n __arm64_sys_close+0x38/0x7c\n invoke_syscall+0x48/0x118\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x4c/0x120\n el0t_64_sync_handler+0x100/0x12c\n el0t_64_sync+0x190/0x194\nirq event stamp: 129818\nhardirqs last  enabled at (129817): [\u0026lt;ffffa5f6d953fcc0\u0026gt;] console_unlock+0x118/0x124\nhardirqs last disabled at (129818): [\u0026lt;ffffa5f6da7dcf04\u0026gt;] el1_dbg+0x24/0x8c\nsoftirqs last  enabled at (129808): [\u0026lt;ffffa5f6d94afc18\u0026gt;] handle_softirqs+0x4c8/0x4e8\nsoftirqs last disabled at (129785): [\u0026lt;ffffa5f6d94105e4\u0026gt;] __do_softirq+0x14/0x20\r\n\r\nPatchwork: https://patchwork.freedesktop.org/patch/600714/(CVE-2024-44982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: MT - limit max slots\r\n\r\nsyzbot is reporting too large allocation at input_mt_init_slots(), for\nnum_slots is supplied from userspace using ioctl(UI_DEV_CREATE).\r\n\r\nSince nobody knows possible max slots, this patch chose 1024.(CVE-2024-45008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetem: fix return value if duplicate enqueue fails\r\n\r\nThere is a bug in netem_enqueue() introduced by\ncommit 5845f706388a (\u0026quot;net: netem: fix skb length BUG_ON in __skb_to_sgvec\u0026quot;)\nthat can lead to a use-after-free.\r\n\r\nThis commit made netem_enqueue() always return NET_XMIT_SUCCESS\nwhen a packet is duplicated, which can cause the parent qdisc\u0026apos;s q.qlen\nto be mistakenly incremented. When this happens qlen_notify() may be\nskipped on the parent during destruction, leaving a dangling pointer\nfor some classful qdiscs like DRR.\r\n\r\nThere are two ways for the bug happen:\r\n\r\n- If the duplicated packet is dropped by rootq-\u0026gt;enqueue() and then\n  the original packet is also dropped.\n- If rootq-\u0026gt;enqueue() sends the duplicated packet to a different qdisc\n  and the original packet is dropped.\r\n\r\nIn both cases NET_XMIT_SUCCESS is returned even though no packets\nare enqueued at the netem qdisc.\r\n\r\nThe fix is to defer the enqueue of the duplicate packet until after\nthe original packet has been guaranteed to return NET_XMIT_SUCCESS.(CVE-2024-45016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE\r\n\r\ncopy_fd_bitmaps(new, old, count) is expected to copy the first\ncount/BITS_PER_LONG bits from old-\u0026gt;full_fds_bits[] and fill\nthe rest with zeroes.  What it does is copying enough words\n(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.\nThat works fine, *if* all bits past the cutoff point are\nclear.  Otherwise we are risking garbage from the last word\nwe\u0026apos;d copied.\r\n\r\nFor most of the callers that is true - expand_fdtable() has\ncount equal to old-\u0026gt;max_fds, so there\u0026apos;s no open descriptors\npast count, let alone fully occupied words in -\u0026gt;open_fds[],\nwhich is what bits in -\u0026gt;full_fds_bits[] correspond to.\r\n\r\nThe other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),\nwhich is the smallest multiple of BITS_PER_LONG that covers all\nopened descriptors below max_fds.  In the common case (copying on\nfork()) max_fds is ~0U, so all opened descriptors will be below\nit and we are fine, by the same reasons why the call in expand_fdtable()\nis safe.\r\n\r\nUnfortunately, there is a case where max_fds is less than that\nand where we might, indeed, end up with junk in -\u0026gt;full_fds_bits[] -\nclose_range(from, to, CLOSE_RANGE_UNSHARE) with\n\t* descriptor table being currently shared\n\t* \u0026apos;to\u0026apos; being above the current capacity of descriptor table\n\t* \u0026apos;from\u0026apos; being just under some chunk of opened descriptors.\nIn that case we end up with observably wrong behaviour - e.g. spawn\na child with CLONE_FILES, get all descriptors in range 0..127 open,\nthen close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending\nup with descriptor #128, despite #64 being observably not open.\r\n\r\nThe minimally invasive fix would be to deal with that in dup_fd().\nIf this proves to add measurable overhead, we can go that way, but\nlet\u0026apos;s try to fix copy_fd_bitmaps() first.\r\n\r\n* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).\n* make copy_fd_bitmaps() take the bitmap size in words, rather than\nbits; it\u0026apos;s \u0026apos;count\u0026apos; argument is always a multiple of BITS_PER_LONG,\nso we are not losing any information, and that way we can use the\nsame helper for all three bitmaps - compiler will see that count\nis a multiple of BITS_PER_LONG for the large ones, so it\u0026apos;ll generate\nplain memcpy()+memset().\r\n\r\nReproducer added to tools/testing/selftests/core/close_range_test.c(CVE-2024-45025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: aacraid: Fix double-free on probe failure\r\n\r\naac_probe_one() calls hardware-specific init functions through the\naac_driver_ident::init pointer, all of which eventually call down to\naac_init_adapter().\r\n\r\nIf aac_init_adapter() fails after allocating memory for aac_dev::queues,\nit frees the memory but does not clear that member.\r\n\r\nAfter the hardware-specific init function returns an error,\naac_probe_one() goes down an error path that frees the memory pointed to\nby aac_dev::queues, resulting.in a double-free.(CVE-2024-46673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: st: fix probed platform device ref count on probe error path\r\n\r\nThe probe function never performs any paltform device allocation, thus\nerror path \u0026quot;undo_platform_dev_alloc\u0026quot; is entirely bogus.  It drops the\nreference count from the platform device being probed.  If error path is\ntriggered, this will lead to unbalanced device reference counts and\npremature release of device resources, thus possible use-after-free when\nreleasing remaining devm-managed resources.(CVE-2024-46674)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nethtool: check device is present when getting link settings\r\n\r\nA sysfs reader can race with a device reset or removal, attempting to\nread device state when the device is not actually present. eg:\r\n\r\n     [exception RIP: qed_get_current_link+17]\n  #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]\n  #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3\n #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4\n #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300\n #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c\n #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b\n #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3\n #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1\n #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f\n #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb\r\n\r\n crash\u0026gt; struct net_device.state ffff9a9d21336000\n    state = 5,\r\n\r\nstate 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).\nThe device is not present, note lack of __LINK_STATE_PRESENT (0b10).\r\n\r\nThis is the same sort of panic as observed in commit 4224cfd7fb65\n(\u0026quot;net-sysfs: add check for netdevice being present to speed_show\u0026quot;).\r\n\r\nThere are many other callers of __ethtool_get_link_ksettings() which\ndon\u0026apos;t have a device presence check.\r\n\r\nMove this check into ethtool to protect all callers.(CVE-2024-46679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npktgen: use cpus_read_lock() in pg_net_init()\r\n\r\nI have seen the WARN_ON(smp_processor_id() != cpu) firing\nin pktgen_thread_worker() during tests.\r\n\r\nWe must use cpus_read_lock()/cpus_read_unlock()\naround the for_each_online_cpu(cpu) loop.\r\n\r\nWhile we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.(CVE-2024-46681)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nselinux,smack: don\u0026apos;t bypass permissions check in inode_setsecctx hook\r\n\r\nMarek Gresko reports that the root user on an NFS client is able to\nchange the security labels on files on an NFS filesystem that is\nexported with root squashing enabled.\r\n\r\nThe end of the kerneldoc comment for __vfs_setxattr_noperm() states:\r\n\r\n *  This function requires the caller to lock the inode\u0026apos;s i_mutex before it\n *  is executed. It also assumes that the caller will make the appropriate\n *  permission checks.\r\n\r\nnfsd_setattr() does do permissions checking via fh_verify() and\nnfsd_permission(), but those don\u0026apos;t do all the same permissions checks\nthat are done by security_inode_setxattr() and its related LSM hooks do.\r\n\r\nSince nfsd_setattr() is the only consumer of security_inode_setsecctx(),\nsimplest solution appears to be to replace the call to\n__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked().  This\nfixes the above issue and has the added benefit of causing nfsd to\nrecall conflicting delegations on a file when a client tries to change\nits security label.(CVE-2024-46695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3\r\n\r\nOn a system with a GICv3, if a guest hasn\u0026apos;t been configured with\nGICv3 and that the host is not capable of GICv2 emulation,\na write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.\r\n\r\nWe therefore try to emulate the SGI access, only to hit a NULL\npointer as no private interrupt is allocated (no GIC, remember?).\r\n\r\nThe obvious fix is to give the guest what it deserves, in the\nshape of a UNDEF exception.(CVE-2024-46707)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\napparmor: fix possible NULL pointer dereference\r\n\r\nprofile-\u0026gt;parent-\u0026gt;dents[AAFS_PROF_DIR] could be NULL only if its parent is made\nfrom __create_missing_ancestors(..) and \u0026apos;ent-\u0026gt;old\u0026apos; is NULL in\naa_replace_profiles(..).\nIn that case, it must return an error code and the code, -ENOENT represents\nits state that the path of its parent is not existed yet.\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000030\nPGD 0 P4D 0\nPREEMPT SMP PTI\nCPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u0026lt;4d\u0026gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x6d/0x80\n ? __die+0x24/0x80\n ? page_fault_oops+0x99/0x1b0\n ? kernelmode_fixup_or_oops+0xb2/0x140\n ? __bad_area_nosemaphore+0x1a5/0x2c0\n ? find_vma+0x34/0x60\n ? bad_area_nosemaphore+0x16/0x30\n ? do_user_addr_fault+0x2a2/0x6b0\n ? exc_page_fault+0x83/0x1b0\n ? asm_exc_page_fault+0x27/0x30\n ? aafs_create.constprop.0+0x7f/0x130\n ? aafs_create.constprop.0+0x51/0x130\n __aafs_profile_mkdir+0x3d6/0x480\n aa_replace_profiles+0x83f/0x1270\n policy_update+0xe3/0x180\n profile_load+0xbc/0x150\n ? rw_verify_area+0x47/0x140\n vfs_write+0x100/0x480\n ? __x64_sys_openat+0x55/0xa0\n ? syscall_exit_to_user_mode+0x86/0x260\n ksys_write+0x73/0x100\n __x64_sys_write+0x19/0x30\n x64_sys_call+0x7e/0x25c0\n do_syscall_64+0x7f/0x180\n entry_SYSCALL_64_after_hwframe+0x78/0x80\nRIP: 0033:0x7be9f211c574\nCode: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89\nRSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574\nRDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004\nRBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000\nR10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80\nR13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30\n \u0026lt;/TASK\u0026gt;\nModules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas\nCR2: 0000000000000030\n---[ end trace 0000000000000000 ]---\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u0026lt;4d\u0026gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000\n---truncated---(CVE-2024-46721)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix out-of-bounds write warning\r\n\r\nCheck the ring type value to fix the out-of-bounds\nwrite warning(CVE-2024-46725)\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\ndrm/amd/display: Assign linear_pitch_alignment even for VM\r\n\r\n[Description]\nAssign linear_pitch_alignment so we don\u0026apos;t cause a divide by 0\nerror in VM environments(CVE-2024-46732)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet-tcp: fix kernel crash if commands allocation fails\r\n\r\nIf the commands allocation fails in nvmet_tcp_alloc_cmds()\nthe kernel crashes in nvmet_tcp_release_queue_work() because of\na NULL pointer dereference.\r\n\r\n  nvmet: failed to install queue 0 cntlid 1 ret 6\n  Unable to handle kernel NULL pointer dereference at\n         virtual address 0000000000000008\r\n\r\nFix the bug by setting queue-\u0026gt;nr_cmds to zero in case\nnvmet_tcp_alloc_cmd() fails.(CVE-2024-46737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nVMCI: Fix use-after-free when removing resource in vmci_resource_remove()\r\n\r\nWhen removing a resource from vmci_resource_table in\nvmci_resource_remove(), the search is performed using the resource\nhandle by comparing context and resource fields.\r\n\r\nIt is possible though to create two resources with different types\nbut same handle (same context and resource fields).\r\n\r\nWhen trying to remove one of the resources, vmci_resource_remove()\nmay not remove the intended one, but the object will still be freed\nas in the case of the datagram type in vmci_datagram_destroy_handle().\nvmci_resource_table will still hold a pointer to this freed resource\nleading to a use-after-free vulnerability.\r\n\r\nBUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\nBUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\nRead of size 4 at addr ffff88801c16d800 by task syz-executor197/1592\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106\n print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239\n __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425\n kasan_report+0x38/0x51 mm/kasan/report.c:442\n vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\n vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\n vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182\n ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444\n kref_put include/linux/kref.h:65 [inline]\n vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]\n vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195\n vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143\n __fput+0x261/0xa34 fs/file_table.c:282\n task_work_run+0xf0/0x194 kernel/task_work.c:164\n tracehook_notify_resume include/linux/tracehook.h:189 [inline]\n exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187\n exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220\n __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]\n syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313\n do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x6e/0x0\r\n\r\nThis change ensures the type is also checked when removing\nthe resource from vmci_resource_table in vmci_resource_remove().(CVE-2024-46738)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nuio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind\r\n\r\nFor primary VM Bus channels, primary_channel pointer is always NULL. This\npointer is valid only for the secondary channels. Also, rescind callback\nis meant for primary channels only.\r\n\r\nFix NULL pointer dereference by retrieving the device_obj from the parent\nfor the primary channel.(CVE-2024-46739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinder: fix UAF caused by offsets overwrite\r\n\r\nBinder objects are processed and copied individually into the target\nbuffer during transactions. Any raw data in-between these objects is\ncopied as well. However, this raw data copy lacks an out-of-bounds\ncheck. If the raw data exceeds the data section size then the copy\noverwrites the offsets section. This eventually triggers an error that\nattempts to unwind the processed objects. However, at this point the\noffsets used to index these objects are now corrupted.\r\n\r\nUnwinding with corrupted offsets can result in decrements of arbitrary\nnodes and lead to their premature release. Other users of such nodes are\nleft with a dangling pointer triggering a use-after-free. This issue is\nmade evident by the following KASAN report (trimmed):\r\n\r\n  ==================================================================\n  BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c\n  Write of size 4 at addr ffff47fc91598f04 by task binder-util/743\r\n\r\n  CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1\n  Hardware name: linux,dummy-virt (DT)\n  Call trace:\n   _raw_spin_lock+0xe4/0x19c\n   binder_free_buf+0x128/0x434\n   binder_thread_write+0x8a4/0x3260\n   binder_ioctl+0x18f0/0x258c\n  [...]\r\n\r\n  Allocated by task 743:\n   __kmalloc_cache_noprof+0x110/0x270\n   binder_new_node+0x50/0x700\n   binder_transaction+0x413c/0x6da8\n   binder_thread_write+0x978/0x3260\n   binder_ioctl+0x18f0/0x258c\n  [...]\r\n\r\n  Freed by task 745:\n   kfree+0xbc/0x208\n   binder_thread_read+0x1c5c/0x37d4\n   binder_ioctl+0x16d8/0x258c\n  [...]\n  ==================================================================\r\n\r\nTo avoid this issue, let\u0026apos;s check that the raw data copy is within the\nboundaries of the data section.(CVE-2024-46740)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open()\r\n\r\nnull-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE)\nand parse_lease_state() return NULL.\r\n\r\nFix this by check if \u0026apos;lease_ctx_info\u0026apos; is NULL.\r\n\r\nAdditionally, remove the redundant parentheses in\nparse_durable_handle_context().(CVE-2024-46742)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof/irq: Prevent device address out-of-bounds read in interrupt map walk\r\n\r\nWhen of_irq_parse_raw() is invoked with a device address smaller than\nthe interrupt parent node (from #address-cells property), KASAN detects\nthe following out-of-bounds read when populating the initial match table\n(dyndbg=\u0026quot;func of_irq_parse_* +p\u0026quot;):\r\n\r\n  OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0\n  OF:  parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2\n  OF:  intspec=4\n  OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2\n  OF:  -\u0026gt; addrsize=3\n  ==================================================================\n  BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0\n  Read of size 4 at addr ffffff81beca5608 by task bash/764\r\n\r\n  CPU: 1 PID: 764 Comm: bash Tainted: G           O       6.1.67-484c613561-nokia_sm_arm64 #1\n  Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023\n  Call trace:\n   dump_backtrace+0xdc/0x130\n   show_stack+0x1c/0x30\n   dump_stack_lvl+0x6c/0x84\n   print_report+0x150/0x448\n   kasan_report+0x98/0x140\n   __asan_load4+0x78/0xa0\n   of_irq_parse_raw+0x2b8/0x8d0\n   of_irq_parse_one+0x24c/0x270\n   parse_interrupts+0xc0/0x120\n   of_fwnode_add_links+0x100/0x2d0\n   fw_devlink_parse_fwtree+0x64/0xc0\n   device_add+0xb38/0xc30\n   of_device_add+0x64/0x90\n   of_platform_device_create_pdata+0xd0/0x170\n   of_platform_bus_create+0x244/0x600\n   of_platform_notify+0x1b0/0x254\n   blocking_notifier_call_chain+0x9c/0xd0\n   __of_changeset_entry_notify+0x1b8/0x230\n   __of_changeset_apply_notify+0x54/0xe4\n   of_overlay_fdt_apply+0xc04/0xd94\n   ...\r\n\r\n  The buggy address belongs to the object at ffffff81beca5600\n   which belongs to the cache kmalloc-128 of size 128\n  The buggy address is located 8 bytes inside of\n   128-byte region [ffffff81beca5600, ffffff81beca5680)\r\n\r\n  The buggy address belongs to the physical page:\n  page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4\n  head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0\n  flags: 0x8000000000010200(slab|head|zone=2)\n  raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300\n  raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000\n  page dumped because: kasan: bad access detected\r\n\r\n  Memory state around the buggy address:\n   ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n   ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n  \u0026gt;ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n                        ^\n   ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n   ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc\n  ==================================================================\n  OF:  -\u0026gt; got it !\r\n\r\nPrevent the out-of-bounds read by copying the device address into a\nbuffer of sufficient size.(CVE-2024-46743)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: Add missing bridge lock to pci_bus_lock()\r\n\r\nOne of the true positives that the cfg_access_lock lockdep effort\nidentified is this sequence:\r\n\r\n  WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70\n  RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? __warn+0x8c/0x190\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   ? report_bug+0x1f8/0x200\n   ? handle_bug+0x3c/0x70\n   ? exc_invalid_op+0x18/0x70\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   pci_reset_bus+0x1d8/0x270\n   vmd_probe+0x778/0xa10\n   pci_device_probe+0x95/0x120\r\n\r\nWhere pci_reset_bus() users are triggering unlocked secondary bus resets.\nIronically pci_bus_reset(), several calls down from pci_reset_bus(), uses\npci_bus_lock() before issuing the reset which locks everything *but* the\nbridge itself.\r\n\r\nFor the same motivation as adding:\r\n\r\n  bridge = pci_upstream_bridge(dev);\n  if (bridge)\n    pci_dev_lock(bridge);\r\n\r\nto pci_reset_function() for the \u0026quot;bus\u0026quot; and \u0026quot;cxl_bus\u0026quot; reset cases, add\npci_dev_lock() for @bus-\u0026gt;self to pci_bus_lock().\r\n\r\n[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:\nhttps://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com](CVE-2024-46750)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: handle errors from btrfs_dec_ref() properly\r\n\r\nIn walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref().  This is\nincorrect, we have proper error handling here, return the error.(CVE-2024-46753)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()\r\n\r\nmwifiex_get_priv_by_id() returns the priv pointer corresponding to\nthe bss_num and bss_type, but without checking if the priv is actually\ncurrently in use.\nUnused priv pointers do not have a wiphy attached to them which can\nlead to NULL pointer dereferences further down the callstack.  Fix\nthis by returning only used priv pointers which have priv-\u0026gt;bss_mode\nset to something else than NL80211_IFTYPE_UNSPECIFIED.\r\n\r\nSaid NULL pointer dereference happened when an Accesspoint was started\nwith wpa_supplicant -i mlan0 with this config:\r\n\r\nnetwork={\n        ssid=\u0026quot;somessid\u0026quot;\n        mode=2\n        frequency=2412\n        key_mgmt=WPA-PSK WPA-PSK-SHA256\n        proto=RSN\n        group=CCMP\n        pairwise=CCMP\n        psk=\u0026quot;12345678\u0026quot;\n}\r\n\r\nWhen waiting for the AP to be established, interrupting wpa_supplicant\nwith \u0026lt;ctrl-c\u0026gt; and starting it again this happens:\r\n\r\n| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140\n| Mem abort info:\n|   ESR = 0x0000000096000004\n|   EC = 0x25: DABT (current EL), IL = 32 bits\n|   SET = 0, FnV = 0\n|   EA = 0, S1PTW = 0\n|   FSC = 0x04: level 0 translation fault\n| Data abort info:\n|   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n|   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n|   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000\n| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000\n| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio\n+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs\n+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6\n| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18\n| Hardware name: somemachine (DT)\n| Workqueue: events sdio_irq_work\n| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]\n| sp : ffff8000818b3a70\n| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004\n| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9\n| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000\n| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000\n| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517\n| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1\n| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157\n| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124\n| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000\n| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000\n| Call trace:\n|  mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n|  mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]\n|  mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]\n|  mwifiex_process_sta_event+0x298/0xf0c [mwifiex]\n|  mwifiex_process_event+0x110/0x238 [mwifiex]\n|  mwifiex_main_process+0x428/0xa44 [mwifiex]\n|  mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]\n|  process_sdio_pending_irqs+0x64/0x1b8\n|  sdio_irq_work+0x4c/0x7c\n|  process_one_work+0x148/0x2a0\n|  worker_thread+0x2fc/0x40c\n|  kthread+0x110/0x114\n|  ret_from_fork+0x10/0x20\n| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)\n| ---[ end trace 0000000000000000 ]---(CVE-2024-46755)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (w83627ehf) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (lm95234) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46758)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (adc128d818) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46759)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npci/hotplug/pnv_php: Fix hotplug driver crash on Powernv\r\n\r\nThe hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel\ncrash when we try to hot-unplug/disable the PCIe switch/bridge from\nthe PHB.\r\n\r\nThe crash occurs because although the MSI data structure has been\nreleased during disable/hot-unplug path and it has been assigned\nwith NULL, still during unregistration the code was again trying to\nexplicitly disable the MSI which causes the NULL pointer dereference and\nkernel crash.\r\n\r\nThe patch fixes the check during unregistration path to prevent invoking\npci_disable_msi/msix() since its data structure is already freed.(CVE-2024-46761)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: bcm: Remove proc entry when dev is unregistered.\r\n\r\nsyzkaller reported a warning in bcm_connect() below. [0]\r\n\r\nThe repro calls connect() to vxcan1, removes vxcan1, and calls\nconnect() with ifindex == 0.\r\n\r\nCalling connect() for a BCM socket allocates a proc entry.\nThen, bcm_sk(sk)-\u0026gt;bound is set to 1 to prevent further connect().\r\n\r\nHowever, removing the bound device resets bcm_sk(sk)-\u0026gt;bound to 0\nin bcm_notify().\r\n\r\nThe 2nd connect() tries to allocate a proc entry with the same\nname and sets NULL to bcm_sk(sk)-\u0026gt;bcm_proc_read, leaking the\noriginal proc entry.\r\n\r\nSince the proc entry is available only for connect()ed sockets,\nlet\u0026apos;s clean up the entry when the bound netdev is unregistered.\r\n\r\n[0]:\nproc_dir_entry \u0026apos;can-bcm/2456\u0026apos; already registered\nWARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375\nModules linked in:\nCPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375\nCode: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 \u0026lt;0f\u0026gt; 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48\nRSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246\nRAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002\nRBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0\nR10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec\nFS:  00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220\n bcm_connect+0x472/0x840 net/can/bcm.c:1673\n __sys_connect_file net/socket.c:2049 [inline]\n __sys_connect+0x5d2/0x690 net/socket.c:2066\n __do_sys_connect net/socket.c:2076 [inline]\n __se_sys_connect net/socket.c:2073 [inline]\n __x64_sys_connect+0x8f/0x100 net/socket.c:2073\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7fbd708b0e5d\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48\nRSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d\nRDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003\nRBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040\nR10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098\nR13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000\n \u0026lt;/TASK\u0026gt;\nremove_proc_entry: removing non-empty directory \u0026apos;net/can-bcm\u0026apos;, leaking at least \u0026apos;2456\u0026apos;(CVE-2024-46771)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nudf: Avoid excessive partition lengths\r\n\r\nAvoid mounting filesystems where the partition would overflow the\n32-bits used for block number. Also refuse to mount filesystems where\nthe partition length is so large we cannot safely index bits in a\nblock bitmap.(CVE-2024-46777)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: protect references to superblock parameters exposed in sysfs\r\n\r\nThe superblock buffers of nilfs2 can not only be overwritten at runtime\nfor modifications/repairs, but they are also regularly swapped, replaced\nduring resizing, and even abandoned when degrading to one side due to\nbacking device issues.  So, accessing them requires mutual exclusion using\nthe reader/writer semaphore \u0026quot;nilfs-\u0026gt;ns_sem\u0026quot;.\r\n\r\nSome sysfs attribute show methods read this superblock buffer without the\nnecessary mutual exclusion, which can cause problems with pointer\ndereferencing and memory access, so fix it.(CVE-2024-46780)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix missing cleanup on rollforward recovery error\r\n\r\nIn an error injection test of a routine for mount-time recovery, KASAN\nfound a use-after-free bug.\r\n\r\nIt turned out that if data recovery was performed using partial logs\ncreated by dsync writes, but an error occurred before starting the log\nwriter to create a recovered checkpoint, the inodes whose data had been\nrecovered were left in the ns_dirty_files list of the nilfs object and\nwere not freed.\r\n\r\nFix this issue by cleaning up inodes that have read the recovery data if\nthe recovery routine fails midway before the log writer starts.(CVE-2024-46781)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open\r\n\r\nThe mcp251x_hw_wake() function is called with the mpc_lock mutex held and\ndisables the interrupt handler so that no interrupts can be processed while\nwaking the device. If an interrupt has already occurred then waiting for\nthe interrupt handler to complete will deadlock because it will be trying\nto acquire the same mutex.\r\n\r\nCPU0                           CPU1\n----                           ----\nmcp251x_open()\n mutex_lock(\u0026amp;priv-\u0026gt;mcp_lock)\n  request_threaded_irq()\n                               \u0026lt;interrupt\u0026gt;\n                               mcp251x_can_ist()\n                                mutex_lock(\u0026amp;priv-\u0026gt;mcp_lock)\n  mcp251x_hw_wake()\n   disable_irq() \u0026lt;-- deadlock\r\n\r\nUse disable_irq_nosync() instead because the interrupt handler does\neverything while holding the mutex so it doesn\u0026apos;t matter if it\u0026apos;s still\nrunning.(CVE-2024-46791)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: dapm: Fix UAF for snd_soc_pcm_runtime object\r\n\r\nWhen using kernel with the following extra config,\r\n\r\n  - CONFIG_KASAN=y\n  - CONFIG_KASAN_GENERIC=y\n  - CONFIG_KASAN_INLINE=y\n  - CONFIG_KASAN_VMALLOC=y\n  - CONFIG_FRAME_WARN=4096\r\n\r\nkernel detects that snd_pcm_suspend_all() access a freed\n\u0026apos;snd_soc_pcm_runtime\u0026apos; object when the system is suspended, which\nleads to a use-after-free bug:\r\n\r\n[   52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270\n[   52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330\r\n\r\n[   52.047785] Call trace:\n[   52.047787]  dump_backtrace+0x0/0x3c0\n[   52.047794]  show_stack+0x34/0x50\n[   52.047797]  dump_stack_lvl+0x68/0x8c\n[   52.047802]  print_address_description.constprop.0+0x74/0x2c0\n[   52.047809]  kasan_report+0x210/0x230\n[   52.047815]  __asan_report_load1_noabort+0x3c/0x50\n[   52.047820]  snd_pcm_suspend_all+0x1a8/0x270\n[   52.047824]  snd_soc_suspend+0x19c/0x4e0\r\n\r\nThe snd_pcm_sync_stop() has a NULL check on \u0026apos;substream-\u0026gt;runtime\u0026apos; before\nmaking any access. So we need to always set \u0026apos;substream-\u0026gt;runtime\u0026apos; to NULL\neverytime we kfree() it.(CVE-2024-46798)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsch/netem: fix use after free in netem_dequeue\r\n\r\nIf netem_dequeue() enqueues packet to inner qdisc and that qdisc\nreturns __NET_XMIT_STOLEN. The packet is dropped but\nqdisc_tree_reduce_backlog() is not called to update the parent\u0026apos;s\nq.qlen, leading to the similar use-after-free as Commit\ne04991a48dbaf382 (\u0026quot;netem: fix return value if duplicate enqueue\nfails\u0026quot;)\r\n\r\nCommands to trigger KASAN UaF:\r\n\r\nip link add type dummy\nip link set lo up\nip link set dummy0 up\ntc qdisc add dev lo parent root handle 1: drr\ntc filter add dev lo parent 1: basic classid 1:1\ntc class add dev lo classid 1:1 drr\ntc qdisc add dev lo parent 1:1 handle 2: netem\ntc qdisc add dev lo parent 2: handle 3: drr\ntc filter add dev lo parent 3: basic classid 3:1 action mirred egress\nredirect dev dummy0\ntc class add dev lo classid 3:1 drr\nping -c1 -W0.01 localhost # Trigger bug\ntc class del dev lo classid 1:1\ntc class add dev lo classid 1:1 drr\nping -c1 -W0.01 localhost # UaF(CVE-2024-46800)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Add array index check for hdcp ddc access\r\n\r\n[Why]\nCoverity reports OVERRUN warning. Do not check if array\nindex valid.\r\n\r\n[How]\nCheck msg_id valid and valid array index.(CVE-2024-46804)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check msg_id before processing transcation\r\n\r\n[WHY \u0026amp; HOW]\nHDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a valid\narray index, and it needs checking before used.\r\n\r\nThis fixes 4 OVERRUN issues reported by Coverity.(CVE-2024-46814)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links\r\n\r\n[Why]\nCoverity report OVERRUN warning. There are\nonly max_links elements within dc-\u0026gt;links. link\ncount could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31.\r\n\r\n[How]\nMake sure link count less than max_links.(CVE-2024-46816)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check gpio_id before used as array index\r\n\r\n[WHY \u0026amp; HOW]\nGPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore\nshould be checked in advance.\r\n\r\nThis fixes 5 OVERRUN issues reported by Coverity.(CVE-2024-46818)\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\nrtmutex: Drop rt_mutex::wait_lock before scheduling\r\n\r\nrt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held.  In the\ngood case it returns with the lock held and in the deadlock case it emits a\nwarning and goes into an endless scheduling loop with the lock held, which\ntriggers the \u0026apos;scheduling in atomic\u0026apos; warning.\r\n\r\nUnlock rt_mutex::wait_lock in the dead lock case before issuing the warning\nand dropping into the schedule for ever loop.\r\n\r\n[ tglx: Moved unlock before the WARN(), removed the pointless comment,\n  \tmassaged changelog, added Fixes tag ](CVE-2024-46829)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don\u0026apos;t BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()\r\n\r\nWe handle errors here properly, ENOMEM isn\u0026apos;t fatal, return the error.(CVE-2024-46841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\num: line: always fill *error_out in setup_one_line()\r\n\r\nThe pointer isn\u0026apos;t initialized by callers, but I have\nencountered cases where it\u0026apos;s still printed; initialize\nit in all possible cases in setup_one_line().(CVE-2024-46844)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: meson: axg-card: fix \u0026apos;use-after-free\u0026apos;\r\n\r\nBuffer \u0026apos;card-\u0026gt;dai_link\u0026apos; is reallocated in \u0026apos;meson_card_reallocate_links()\u0026apos;,\nso move \u0026apos;pad\u0026apos; pointer initialization after this function when memory is\nalready reallocated.\r\n\r\nKasan bug report:\r\n\r\n==================================================================\nBUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc\nRead of size 8 at addr ffff000000e8b260 by task modprobe/356\r\n\r\nCPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1\nCall trace:\n dump_backtrace+0x94/0xec\n show_stack+0x18/0x24\n dump_stack_lvl+0x78/0x90\n print_report+0xfc/0x5c0\n kasan_report+0xb8/0xfc\n __asan_load8+0x9c/0xb8\n axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card]\n meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils]\n platform_probe+0x8c/0xf4\n really_probe+0x110/0x39c\n __driver_probe_device+0xb8/0x18c\n driver_probe_device+0x108/0x1d8\n __driver_attach+0xd0/0x25c\n bus_for_each_dev+0xe0/0x154\n driver_attach+0x34/0x44\n bus_add_driver+0x134/0x294\n driver_register+0xa8/0x1e8\n __platform_driver_register+0x44/0x54\n axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card]\n do_one_initcall+0xdc/0x25c\n do_init_module+0x10c/0x334\n load_module+0x24c4/0x26cc\n init_module_from_file+0xd4/0x128\n __arm64_sys_finit_module+0x1f4/0x41c\n invoke_syscall+0x60/0x188\n el0_svc_common.constprop.0+0x78/0x13c\n do_el0_svc+0x30/0x40\n el0_svc+0x38/0x78\n el0t_64_sync_handler+0x100/0x12c\n el0t_64_sync+0x190/0x194(CVE-2024-46849)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Fix bridge mode operations when there are no VFs\r\n\r\nCurrently, trying to set the bridge mode attribute when numvfs=0 leads to a\ncrash:\r\n\r\nbridge link set dev eth2 hwmode vepa\r\n\r\n[  168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030\n[...]\n[  168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core]\n[...]\n[  168.976037] Call Trace:\n[  168.976188]  \u0026lt;TASK\u0026gt;\n[  168.978620]  _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core]\n[  168.979074]  mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core]\n[  168.979471]  rtnl_bridge_setlink+0xe9/0x1f0\n[  168.979714]  rtnetlink_rcv_msg+0x159/0x400\n[  168.980451]  netlink_rcv_skb+0x54/0x100\n[  168.980675]  netlink_unicast+0x241/0x360\n[  168.980918]  netlink_sendmsg+0x1f6/0x430\n[  168.981162]  ____sys_sendmsg+0x3bb/0x3f0\n[  168.982155]  ___sys_sendmsg+0x88/0xd0\n[  168.985036]  __sys_sendmsg+0x59/0xa0\n[  168.985477]  do_syscall_64+0x79/0x150\n[  168.987273]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  168.987773] RIP: 0033:0x7f8f7950f917\r\n\r\n(esw-\u0026gt;fdb_table.legacy.vepa_fdb is null)\r\n\r\nThe bridge mode is only relevant when there are multiple functions per\nport. Therefore, prevent setting and getting this setting when there are no\nVFs.\r\n\r\nNote that after this change, there are no settings to change on the PF\ninterface using `bridge link` when there are no VFs, so the interface no\nlonger appears in the `bridge link` output.(CVE-2024-46857)",
  "id": "OESA-2024-2218",
  "modified": "2026-08-06T11:07:41Z",
  "published": "2024-10-12T11:07:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2218"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27436"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36894"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38560"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38659"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39482"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39501"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40978"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41030"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41095"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43846"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43863"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43900"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44939"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44954"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44958"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44982"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45008"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45016"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45025"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46673"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46674"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46679"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46681"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46695"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46707"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46721"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46725"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46726"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46732"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46737"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46738"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46739"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46740"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46742"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46743"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46750"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46753"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46755"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46756"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46758"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46759"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46761"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46771"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46777"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46780"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46781"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46791"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46798"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46800"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46804"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46814"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46816"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46818"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46821"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46829"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46841"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46844"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46849"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46857"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-27436",
    "CVE-2024-36894",
    "CVE-2024-38560",
    "CVE-2024-38659",
    "CVE-2024-39482",
    "CVE-2024-39501",
    "CVE-2024-40978",
    "CVE-2024-41030",
    "CVE-2024-41095",
    "CVE-2024-43846",
    "CVE-2024-43863",
    "CVE-2024-43900",
    "CVE-2024-44939",
    "CVE-2024-44954",
    "CVE-2024-44958",
    "CVE-2024-44982",
    "CVE-2024-45008",
    "CVE-2024-45016",
    "CVE-2024-45025",
    "CVE-2024-46673",
    "CVE-2024-46674",
    "CVE-2024-46679",
    "CVE-2024-46681",
    "CVE-2024-46695",
    "CVE-2024-46707",
    "CVE-2024-46721",
    "CVE-2024-46725",
    "CVE-2024-46726",
    "CVE-2024-46732",
    "CVE-2024-46737",
    "CVE-2024-46738",
    "CVE-2024-46739",
    "CVE-2024-46740",
    "CVE-2024-46742",
    "CVE-2024-46743",
    "CVE-2024-46750",
    "CVE-2024-46753",
    "CVE-2024-46755",
    "CVE-2024-46756",
    "CVE-2024-46758",
    "CVE-2024-46759",
    "CVE-2024-46761",
    "CVE-2024-46771",
    "CVE-2024-46777",
    "CVE-2024-46780",
    "CVE-2024-46781",
    "CVE-2024-46791",
    "CVE-2024-46798",
    "CVE-2024-46800",
    "CVE-2024-46804",
    "CVE-2024-46814",
    "CVE-2024-46816",
    "CVE-2024-46818",
    "CVE-2024-46821",
    "CVE-2024-46829",
    "CVE-2024-46841",
    "CVE-2024-46844",
    "CVE-2024-46849",
    "CVE-2024-46857"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-231.0.0.130.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-231.0.0.130.oe2203sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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\nbcache: fix variable length array abuse in btree_iter\r\n\r\nbtree_iter is used in two ways: either allocated on the stack with a\nfixed size MAX_BSETS, or from a mempool with a dynamic size based on the\nspecific cache set. Previously, the struct had a fixed-length array of\nsize MAX_BSETS which was indexed out-of-bounds for the dynamically-sized\niterators, which causes UBSAN to complain.\r\n\r\nThis patch uses the same approach as in bcachefs\u0026apos;s sort_iter and splits\nthe iterator into a btree_iter with a flexible array member and a\nbtree_iter_stack which embeds a btree_iter as well as a fixed-length\ndata array.(CVE-2024-39482)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: discard write access to the directory open\r\n\r\nmay_open() does not allow a directory to be opened with the write access.\nHowever, some writing flags set by client result in adding write access\non server, making ksmbd incompatible with FUSE file system. Simply, let\u0026apos;s\ndiscard the write access when opening a directory.\r\n\r\nlist_add corruption. next is NULL.\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:26!\npc : __list_add_valid+0x88/0xbc\nlr : __list_add_valid+0x88/0xbc\nCall trace:\n__list_add_valid+0x88/0xbc\nfuse_finish_open+0x11c/0x170\nfuse_open_common+0x284/0x5e8\nfuse_dir_open+0x14/0x24\ndo_dentry_open+0x2a4/0x4e0\ndentry_open+0x50/0x80\nsmb2_open+0xbe4/0x15a4\nhandle_ksmbd_work+0x478/0x5ec\nprocess_one_work+0x1b4/0x448\nworker_thread+0x25c/0x430\nkthread+0x104/0x1d4\nret_from_fork+0x10/0x20(CVE-2024-41030)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes\r\n\r\nIn nv17_tv_get_ld_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-41095)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: xc2028: avoid use-after-free in load_firmware_cb()\r\n\r\nsyzkaller reported use-after-free in load_firmware_cb() [1].\nThe reason is because the module allocated a struct tuner in tuner_probe(),\nand then the module initialization failed, the struct tuner was released.\nA worker which created during module initialization accesses this struct\ntuner later, it caused use-after-free.\r\n\r\nThe process is as follows:\r\n\r\ntask-6504           worker_thread\ntuner_probe                             \u0026lt;= alloc dvb_frontend [2]\n...\nrequest_firmware_nowait                 \u0026lt;= create a worker\n...\ntuner_remove                            \u0026lt;= free dvb_frontend\n...\n                    request_firmware_work_func  \u0026lt;= the firmware is ready\n                    load_firmware_cb    \u0026lt;= but now the dvb_frontend has been freed\r\n\r\nTo fix the issue, check the dvd_frontend in load_firmware_cb(), if it is\nnull, report a warning and just return.\r\n\r\n[1]:\n    ==================================================================\n     BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0\n     Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504\r\n\r\n     Call trace:\n      load_firmware_cb+0x1310/0x17a0\n      request_firmware_work_func+0x128/0x220\n      process_one_work+0x770/0x1824\n      worker_thread+0x488/0xea0\n      kthread+0x300/0x430\n      ret_from_fork+0x10/0x20\r\n\r\n     Allocated by task 6504:\n      kzalloc\n      tuner_probe+0xb0/0x1430\n      i2c_device_probe+0x92c/0xaf0\n      really_probe+0x678/0xcd0\n      driver_probe_device+0x280/0x370\n      __device_attach_driver+0x220/0x330\n      bus_for_each_drv+0x134/0x1c0\n      __device_attach+0x1f4/0x410\n      device_initial_probe+0x20/0x30\n      bus_probe_device+0x184/0x200\n      device_add+0x924/0x12c0\n      device_register+0x24/0x30\n      i2c_new_device+0x4e0/0xc44\n      v4l2_i2c_new_subdev_board+0xbc/0x290\n      v4l2_i2c_new_subdev+0xc8/0x104\n      em28xx_v4l2_init+0x1dd0/0x3770\r\n\r\n     Freed by task 6504:\n      kfree+0x238/0x4e4\n      tuner_remove+0x144/0x1c0\n      i2c_device_remove+0xc8/0x290\n      __device_release_driver+0x314/0x5fc\n      device_release_driver+0x30/0x44\n      bus_remove_device+0x244/0x490\n      device_del+0x350/0x900\n      device_unregister+0x28/0xd0\n      i2c_unregister_device+0x174/0x1d0\n      v4l2_device_unregister+0x224/0x380\n      em28xx_v4l2_init+0x1d90/0x3770\r\n\r\n     The buggy address belongs to the object at ffff8000d7ca2000\n      which belongs to the cache kmalloc-2k of size 2048\n     The buggy address is located 776 bytes inside of\n      2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)\n     The buggy address belongs to the page:\n     page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0\n     flags: 0x7ff800000000100(slab)\n     raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000\n     raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000\n     page dumped because: kasan: bad access detected\r\n\r\n     Memory state around the buggy address:\n      ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n      ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     \u0026gt;ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                           ^\n      ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n      ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     ==================================================================\r\n\r\n[2]\n    Actually, it is allocated for struct tuner, and dvb_frontend is inside.(CVE-2024-43900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched/smt: Fix unbalance sched_smt_present dec/inc\r\n\r\nI got the following warn report while doing stress test:\r\n\r\njump label: negative count!\nWARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __static_key_slow_dec_cpuslocked+0x16/0x70\n sched_cpu_deactivate+0x26e/0x2a0\n cpuhp_invoke_callback+0x3ad/0x10d0\n cpuhp_thread_fun+0x3f5/0x680\n smpboot_thread_fn+0x56d/0x8d0\n kthread+0x309/0x400\n ret_from_fork+0x41/0x70\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nBecause when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),\nthe cpu offline failed, but sched_smt_present is decremented before\ncalling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so\nfix it by incrementing sched_smt_present in the error path.(CVE-2024-44958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/msm/dpu: cleanup FB if dpu_format_populate_layout fails\r\n\r\nIf the dpu_format_populate_layout() fails, then FB is prepared, but not\ncleaned up. This ends up leaking the pin_count on the GEM object and\ncauses a splat during DRM file closure:\r\n\r\nmsm_obj-\u0026gt;pin_count\nWARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc\n[...]\nCall trace:\n update_lru_locked+0xc4/0xcc\n put_pages+0xac/0x100\n msm_gem_free_object+0x138/0x180\n drm_gem_object_free+0x1c/0x30\n drm_gem_object_handle_put_unlocked+0x108/0x10c\n drm_gem_object_release_handle+0x58/0x70\n idr_for_each+0x68/0xec\n drm_gem_release+0x28/0x40\n drm_file_free+0x174/0x234\n drm_release+0xb0/0x160\n __fput+0xc0/0x2c8\n __fput_sync+0x50/0x5c\n __arm64_sys_close+0x38/0x7c\n invoke_syscall+0x48/0x118\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x4c/0x120\n el0t_64_sync_handler+0x100/0x12c\n el0t_64_sync+0x190/0x194\nirq event stamp: 129818\nhardirqs last  enabled at (129817): [\u0026lt;ffffa5f6d953fcc0\u0026gt;] console_unlock+0x118/0x124\nhardirqs last disabled at (129818): [\u0026lt;ffffa5f6da7dcf04\u0026gt;] el1_dbg+0x24/0x8c\nsoftirqs last  enabled at (129808): [\u0026lt;ffffa5f6d94afc18\u0026gt;] handle_softirqs+0x4c8/0x4e8\nsoftirqs last disabled at (129785): [\u0026lt;ffffa5f6d94105e4\u0026gt;] __do_softirq+0x14/0x20\r\n\r\nPatchwork: https://patchwork.freedesktop.org/patch/600714/(CVE-2024-44982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: MT - limit max slots\r\n\r\nsyzbot is reporting too large allocation at input_mt_init_slots(), for\nnum_slots is supplied from userspace using ioctl(UI_DEV_CREATE).\r\n\r\nSince nobody knows possible max slots, this patch chose 1024.(CVE-2024-45008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetem: fix return value if duplicate enqueue fails\r\n\r\nThere is a bug in netem_enqueue() introduced by\ncommit 5845f706388a (\u0026quot;net: netem: fix skb length BUG_ON in __skb_to_sgvec\u0026quot;)\nthat can lead to a use-after-free.\r\n\r\nThis commit made netem_enqueue() always return NET_XMIT_SUCCESS\nwhen a packet is duplicated, which can cause the parent qdisc\u0026apos;s q.qlen\nto be mistakenly incremented. When this happens qlen_notify() may be\nskipped on the parent during destruction, leaving a dangling pointer\nfor some classful qdiscs like DRR.\r\n\r\nThere are two ways for the bug happen:\r\n\r\n- If the duplicated packet is dropped by rootq-\u0026gt;enqueue() and then\n  the original packet is also dropped.\n- If rootq-\u0026gt;enqueue() sends the duplicated packet to a different qdisc\n  and the original packet is dropped.\r\n\r\nIn both cases NET_XMIT_SUCCESS is returned even though no packets\nare enqueued at the netem qdisc.\r\n\r\nThe fix is to defer the enqueue of the duplicate packet until after\nthe original packet has been guaranteed to return NET_XMIT_SUCCESS.(CVE-2024-45016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: aacraid: Fix double-free on probe failure\r\n\r\naac_probe_one() calls hardware-specific init functions through the\naac_driver_ident::init pointer, all of which eventually call down to\naac_init_adapter().\r\n\r\nIf aac_init_adapter() fails after allocating memory for aac_dev::queues,\nit frees the memory but does not clear that member.\r\n\r\nAfter the hardware-specific init function returns an error,\naac_probe_one() goes down an error path that frees the memory pointed to\nby aac_dev::queues, resulting.in a double-free.(CVE-2024-46673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: st: fix probed platform device ref count on probe error path\r\n\r\nThe probe function never performs any paltform device allocation, thus\nerror path \u0026quot;undo_platform_dev_alloc\u0026quot; is entirely bogus.  It drops the\nreference count from the platform device being probed.  If error path is\ntriggered, this will lead to unbalanced device reference counts and\npremature release of device resources, thus possible use-after-free when\nreleasing remaining devm-managed resources.(CVE-2024-46674)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nethtool: check device is present when getting link settings\r\n\r\nA sysfs reader can race with a device reset or removal, attempting to\nread device state when the device is not actually present. eg:\r\n\r\n     [exception RIP: qed_get_current_link+17]\n  #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]\n  #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3\n #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4\n #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300\n #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c\n #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b\n #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3\n #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1\n #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f\n #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb\r\n\r\n crash\u0026gt; struct net_device.state ffff9a9d21336000\n    state = 5,\r\n\r\nstate 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).\nThe device is not present, note lack of __LINK_STATE_PRESENT (0b10).\r\n\r\nThis is the same sort of panic as observed in commit 4224cfd7fb65\n(\u0026quot;net-sysfs: add check for netdevice being present to speed_show\u0026quot;).\r\n\r\nThere are many other callers of __ethtool_get_link_ksettings() which\ndon\u0026apos;t have a device presence check.\r\n\r\nMove this check into ethtool to protect all callers.(CVE-2024-46679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npktgen: use cpus_read_lock() in pg_net_init()\r\n\r\nI have seen the WARN_ON(smp_processor_id() != cpu) firing\nin pktgen_thread_worker() during tests.\r\n\r\nWe must use cpus_read_lock()/cpus_read_unlock()\naround the for_each_online_cpu(cpu) loop.\r\n\r\nWhile we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.(CVE-2024-46681)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nselinux,smack: don\u0026apos;t bypass permissions check in inode_setsecctx hook\r\n\r\nMarek Gresko reports that the root user on an NFS client is able to\nchange the security labels on files on an NFS filesystem that is\nexported with root squashing enabled.\r\n\r\nThe end of the kerneldoc comment for __vfs_setxattr_noperm() states:\r\n\r\n *  This function requires the caller to lock the inode\u0026apos;s i_mutex before it\n *  is executed. It also assumes that the caller will make the appropriate\n *  permission checks.\r\n\r\nnfsd_setattr() does do permissions checking via fh_verify() and\nnfsd_permission(), but those don\u0026apos;t do all the same permissions checks\nthat are done by security_inode_setxattr() and its related LSM hooks do.\r\n\r\nSince nfsd_setattr() is the only consumer of security_inode_setsecctx(),\nsimplest solution appears to be to replace the call to\n__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked().  This\nfixes the above issue and has the added benefit of causing nfsd to\nrecall conflicting delegations on a file when a client tries to change\nits security label.(CVE-2024-46695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3\r\n\r\nOn a system with a GICv3, if a guest hasn\u0026apos;t been configured with\nGICv3 and that the host is not capable of GICv2 emulation,\na write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.\r\n\r\nWe therefore try to emulate the SGI access, only to hit a NULL\npointer as no private interrupt is allocated (no GIC, remember?).\r\n\r\nThe obvious fix is to give the guest what it deserves, in the\nshape of a UNDEF exception.(CVE-2024-46707)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\napparmor: fix possible NULL pointer dereference\r\n\r\nprofile-\u0026gt;parent-\u0026gt;dents[AAFS_PROF_DIR] could be NULL only if its parent is made\nfrom __create_missing_ancestors(..) and \u0026apos;ent-\u0026gt;old\u0026apos; is NULL in\naa_replace_profiles(..).\nIn that case, it must return an error code and the code, -ENOENT represents\nits state that the path of its parent is not existed yet.\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000030\nPGD 0 P4D 0\nPREEMPT SMP PTI\nCPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u0026lt;4d\u0026gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x6d/0x80\n ? __die+0x24/0x80\n ? page_fault_oops+0x99/0x1b0\n ? kernelmode_fixup_or_oops+0xb2/0x140\n ? __bad_area_nosemaphore+0x1a5/0x2c0\n ? find_vma+0x34/0x60\n ? bad_area_nosemaphore+0x16/0x30\n ? do_user_addr_fault+0x2a2/0x6b0\n ? exc_page_fault+0x83/0x1b0\n ? asm_exc_page_fault+0x27/0x30\n ? aafs_create.constprop.0+0x7f/0x130\n ? aafs_create.constprop.0+0x51/0x130\n __aafs_profile_mkdir+0x3d6/0x480\n aa_replace_profiles+0x83f/0x1270\n policy_update+0xe3/0x180\n profile_load+0xbc/0x150\n ? rw_verify_area+0x47/0x140\n vfs_write+0x100/0x480\n ? __x64_sys_openat+0x55/0xa0\n ? syscall_exit_to_user_mode+0x86/0x260\n ksys_write+0x73/0x100\n __x64_sys_write+0x19/0x30\n x64_sys_call+0x7e/0x25c0\n do_syscall_64+0x7f/0x180\n entry_SYSCALL_64_after_hwframe+0x78/0x80\nRIP: 0033:0x7be9f211c574\nCode: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89\nRSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574\nRDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004\nRBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000\nR10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80\nR13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30\n \u0026lt;/TASK\u0026gt;\nModules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas\nCR2: 0000000000000030\n---[ end trace 0000000000000000 ]---\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u0026lt;4d\u0026gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000\n---truncated---(CVE-2024-46721)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix out-of-bounds write warning\r\n\r\nCheck the ring type value to fix the out-of-bounds\nwrite warning(CVE-2024-46725)\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\ndrm/amd/display: Assign linear_pitch_alignment even for VM\r\n\r\n[Description]\nAssign linear_pitch_alignment so we don\u0026apos;t cause a divide by 0\nerror in VM environments(CVE-2024-46732)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet-tcp: fix kernel crash if commands allocation fails\r\n\r\nIf the commands allocation fails in nvmet_tcp_alloc_cmds()\nthe kernel crashes in nvmet_tcp_release_queue_work() because of\na NULL pointer dereference.\r\n\r\n  nvmet: failed to install queue 0 cntlid 1 ret 6\n  Unable to handle kernel NULL pointer dereference at\n         virtual address 0000000000000008\r\n\r\nFix the bug by setting queue-\u0026gt;nr_cmds to zero in case\nnvmet_tcp_alloc_cmd() fails.(CVE-2024-46737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nVMCI: Fix use-after-free when removing resource in vmci_resource_remove()\r\n\r\nWhen removing a resource from vmci_resource_table in\nvmci_resource_remove(), the search is performed using the resource\nhandle by comparing context and resource fields.\r\n\r\nIt is possible though to create two resources with different types\nbut same handle (same context and resource fields).\r\n\r\nWhen trying to remove one of the resources, vmci_resource_remove()\nmay not remove the intended one, but the object will still be freed\nas in the case of the datagram type in vmci_datagram_destroy_handle().\nvmci_resource_table will still hold a pointer to this freed resource\nleading to a use-after-free vulnerability.\r\n\r\nBUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\nBUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\nRead of size 4 at addr ffff88801c16d800 by task syz-executor197/1592\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106\n print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239\n __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425\n kasan_report+0x38/0x51 mm/kasan/report.c:442\n vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\n vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\n vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182\n ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444\n kref_put include/linux/kref.h:65 [inline]\n vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]\n vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195\n vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143\n __fput+0x261/0xa34 fs/file_table.c:282\n task_work_run+0xf0/0x194 kernel/task_work.c:164\n tracehook_notify_resume include/linux/tracehook.h:189 [inline]\n exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187\n exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220\n __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]\n syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313\n do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x6e/0x0\r\n\r\nThis change ensures the type is also checked when removing\nthe resource from vmci_resource_table in vmci_resource_remove().(CVE-2024-46738)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nuio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind\r\n\r\nFor primary VM Bus channels, primary_channel pointer is always NULL. This\npointer is valid only for the secondary channels. Also, rescind callback\nis meant for primary channels only.\r\n\r\nFix NULL pointer dereference by retrieving the device_obj from the parent\nfor the primary channel.(CVE-2024-46739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinder: fix UAF caused by offsets overwrite\r\n\r\nBinder objects are processed and copied individually into the target\nbuffer during transactions. Any raw data in-between these objects is\ncopied as well. However, this raw data copy lacks an out-of-bounds\ncheck. If the raw data exceeds the data section size then the copy\noverwrites the offsets section. This eventually triggers an error that\nattempts to unwind the processed objects. However, at this point the\noffsets used to index these objects are now corrupted.\r\n\r\nUnwinding with corrupted offsets can result in decrements of arbitrary\nnodes and lead to their premature release. Other users of such nodes are\nleft with a dangling pointer triggering a use-after-free. This issue is\nmade evident by the following KASAN report (trimmed):\r\n\r\n  ==================================================================\n  BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c\n  Write of size 4 at addr ffff47fc91598f04 by task binder-util/743\r\n\r\n  CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1\n  Hardware name: linux,dummy-virt (DT)\n  Call trace:\n   _raw_spin_lock+0xe4/0x19c\n   binder_free_buf+0x128/0x434\n   binder_thread_write+0x8a4/0x3260\n   binder_ioctl+0x18f0/0x258c\n  [...]\r\n\r\n  Allocated by task 743:\n   __kmalloc_cache_noprof+0x110/0x270\n   binder_new_node+0x50/0x700\n   binder_transaction+0x413c/0x6da8\n   binder_thread_write+0x978/0x3260\n   binder_ioctl+0x18f0/0x258c\n  [...]\r\n\r\n  Freed by task 745:\n   kfree+0xbc/0x208\n   binder_thread_read+0x1c5c/0x37d4\n   binder_ioctl+0x16d8/0x258c\n  [...]\n  ==================================================================\r\n\r\nTo avoid this issue, let\u0026apos;s check that the raw data copy is within the\nboundaries of the data section.(CVE-2024-46740)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof/irq: Prevent device address out-of-bounds read in interrupt map walk\r\n\r\nWhen of_irq_parse_raw() is invoked with a device address smaller than\nthe interrupt parent node (from #address-cells property), KASAN detects\nthe following out-of-bounds read when populating the initial match table\n(dyndbg=\u0026quot;func of_irq_parse_* +p\u0026quot;):\r\n\r\n  OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0\n  OF:  parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2\n  OF:  intspec=4\n  OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2\n  OF:  -\u0026gt; addrsize=3\n  ==================================================================\n  BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0\n  Read of size 4 at addr ffffff81beca5608 by task bash/764\r\n\r\n  CPU: 1 PID: 764 Comm: bash Tainted: G           O       6.1.67-484c613561-nokia_sm_arm64 #1\n  Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023\n  Call trace:\n   dump_backtrace+0xdc/0x130\n   show_stack+0x1c/0x30\n   dump_stack_lvl+0x6c/0x84\n   print_report+0x150/0x448\n   kasan_report+0x98/0x140\n   __asan_load4+0x78/0xa0\n   of_irq_parse_raw+0x2b8/0x8d0\n   of_irq_parse_one+0x24c/0x270\n   parse_interrupts+0xc0/0x120\n   of_fwnode_add_links+0x100/0x2d0\n   fw_devlink_parse_fwtree+0x64/0xc0\n   device_add+0xb38/0xc30\n   of_device_add+0x64/0x90\n   of_platform_device_create_pdata+0xd0/0x170\n   of_platform_bus_create+0x244/0x600\n   of_platform_notify+0x1b0/0x254\n   blocking_notifier_call_chain+0x9c/0xd0\n   __of_changeset_entry_notify+0x1b8/0x230\n   __of_changeset_apply_notify+0x54/0xe4\n   of_overlay_fdt_apply+0xc04/0xd94\n   ...\r\n\r\n  The buggy address belongs to the object at ffffff81beca5600\n   which belongs to the cache kmalloc-128 of size 128\n  The buggy address is located 8 bytes inside of\n   128-byte region [ffffff81beca5600, ffffff81beca5680)\r\n\r\n  The buggy address belongs to the physical page:\n  page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4\n  head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0\n  flags: 0x8000000000010200(slab|head|zone=2)\n  raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300\n  raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000\n  page dumped because: kasan: bad access detected\r\n\r\n  Memory state around the buggy address:\n   ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n   ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n  \u0026gt;ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n                        ^\n   ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n   ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc\n  ==================================================================\n  OF:  -\u0026gt; got it !\r\n\r\nPrevent the out-of-bounds read by copying the device address into a\nbuffer of sufficient size.(CVE-2024-46743)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: Add missing bridge lock to pci_bus_lock()\r\n\r\nOne of the true positives that the cfg_access_lock lockdep effort\nidentified is this sequence:\r\n\r\n  WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70\n  RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? __warn+0x8c/0x190\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   ? report_bug+0x1f8/0x200\n   ? handle_bug+0x3c/0x70\n   ? exc_invalid_op+0x18/0x70\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   pci_reset_bus+0x1d8/0x270\n   vmd_probe+0x778/0xa10\n   pci_device_probe+0x95/0x120\r\n\r\nWhere pci_reset_bus() users are triggering unlocked secondary bus resets.\nIronically pci_bus_reset(), several calls down from pci_reset_bus(), uses\npci_bus_lock() before issuing the reset which locks everything *but* the\nbridge itself.\r\n\r\nFor the same motivation as adding:\r\n\r\n  bridge = pci_upstream_bridge(dev);\n  if (bridge)\n    pci_dev_lock(bridge);\r\n\r\nto pci_reset_function() for the \u0026quot;bus\u0026quot; and \u0026quot;cxl_bus\u0026quot; reset cases, add\npci_dev_lock() for @bus-\u0026gt;self to pci_bus_lock().\r\n\r\n[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:\nhttps://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com](CVE-2024-46750)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: handle errors from btrfs_dec_ref() properly\r\n\r\nIn walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref().  This is\nincorrect, we have proper error handling here, return the error.(CVE-2024-46753)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()\r\n\r\nmwifiex_get_priv_by_id() returns the priv pointer corresponding to\nthe bss_num and bss_type, but without checking if the priv is actually\ncurrently in use.\nUnused priv pointers do not have a wiphy attached to them which can\nlead to NULL pointer dereferences further down the callstack.  Fix\nthis by returning only used priv pointers which have priv-\u0026gt;bss_mode\nset to something else than NL80211_IFTYPE_UNSPECIFIED.\r\n\r\nSaid NULL pointer dereference happened when an Accesspoint was started\nwith wpa_supplicant -i mlan0 with this config:\r\n\r\nnetwork={\n        ssid=\u0026quot;somessid\u0026quot;\n        mode=2\n        frequency=2412\n        key_mgmt=WPA-PSK WPA-PSK-SHA256\n        proto=RSN\n        group=CCMP\n        pairwise=CCMP\n        psk=\u0026quot;12345678\u0026quot;\n}\r\n\r\nWhen waiting for the AP to be established, interrupting wpa_supplicant\nwith \u0026lt;ctrl-c\u0026gt; and starting it again this happens:\r\n\r\n| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140\n| Mem abort info:\n|   ESR = 0x0000000096000004\n|   EC = 0x25: DABT (current EL), IL = 32 bits\n|   SET = 0, FnV = 0\n|   EA = 0, S1PTW = 0\n|   FSC = 0x04: level 0 translation fault\n| Data abort info:\n|   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n|   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n|   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000\n| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000\n| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio\n+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs\n+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6\n| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18\n| Hardware name: somemachine (DT)\n| Workqueue: events sdio_irq_work\n| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]\n| sp : ffff8000818b3a70\n| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004\n| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9\n| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000\n| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000\n| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517\n| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1\n| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157\n| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124\n| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000\n| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000\n| Call trace:\n|  mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n|  mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]\n|  mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]\n|  mwifiex_process_sta_event+0x298/0xf0c [mwifiex]\n|  mwifiex_process_event+0x110/0x238 [mwifiex]\n|  mwifiex_main_process+0x428/0xa44 [mwifiex]\n|  mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]\n|  process_sdio_pending_irqs+0x64/0x1b8\n|  sdio_irq_work+0x4c/0x7c\n|  process_one_work+0x148/0x2a0\n|  worker_thread+0x2fc/0x40c\n|  kthread+0x110/0x114\n|  ret_from_fork+0x10/0x20\n| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)\n| ---[ end trace 0000000000000000 ]---(CVE-2024-46755)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (w83627ehf) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (lm95234) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46758)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (adc128d818) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46759)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npci/hotplug/pnv_php: Fix hotplug driver crash on Powernv\r\n\r\nThe hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel\ncrash when we try to hot-unplug/disable the PCIe switch/bridge from\nthe PHB.\r\n\r\nThe crash occurs because although the MSI data structure has been\nreleased during disable/hot-unplug path and it has been assigned\nwith NULL, still during unregistration the code was again trying to\nexplicitly disable the MSI which causes the NULL pointer dereference and\nkernel crash.\r\n\r\nThe patch fixes the check during unregistration path to prevent invoking\npci_disable_msi/msix() since its data structure is already freed.(CVE-2024-46761)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: bcm: Remove proc entry when dev is unregistered.\r\n\r\nsyzkaller reported a warning in bcm_connect() below. [0]\r\n\r\nThe repro calls connect() to vxcan1, removes vxcan1, and calls\nconnect() with ifindex == 0.\r\n\r\nCalling connect() for a BCM socket allocates a proc entry.\nThen, bcm_sk(sk)-\u0026gt;bound is set to 1 to prevent further connect().\r\n\r\nHowever, removing the bound device resets bcm_sk(sk)-\u0026gt;bound to 0\nin bcm_notify().\r\n\r\nThe 2nd connect() tries to allocate a proc entry with the same\nname and sets NULL to bcm_sk(sk)-\u0026gt;bcm_proc_read, leaking the\noriginal proc entry.\r\n\r\nSince the proc entry is available only for connect()ed sockets,\nlet\u0026apos;s clean up the entry when the bound netdev is unregistered.\r\n\r\n[0]:\nproc_dir_entry \u0026apos;can-bcm/2456\u0026apos; already registered\nWARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375\nModules linked in:\nCPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375\nCode: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 \u0026lt;0f\u0026gt; 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48\nRSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246\nRAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002\nRBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0\nR10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec\nFS:  00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220\n bcm_connect+0x472/0x840 net/can/bcm.c:1673\n __sys_connect_file net/socket.c:2049 [inline]\n __sys_connect+0x5d2/0x690 net/socket.c:2066\n __do_sys_connect net/socket.c:2076 [inline]\n __se_sys_connect net/socket.c:2073 [inline]\n __x64_sys_connect+0x8f/0x100 net/socket.c:2073\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7fbd708b0e5d\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48\nRSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d\nRDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003\nRBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040\nR10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098\nR13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000\n \u0026lt;/TASK\u0026gt;\nremove_proc_entry: removing non-empty directory \u0026apos;net/can-bcm\u0026apos;, leaking at least \u0026apos;2456\u0026apos;(CVE-2024-46771)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nudf: Avoid excessive partition lengths\r\n\r\nAvoid mounting filesystems where the partition would overflow the\n32-bits used for block number. Also refuse to mount filesystems where\nthe partition length is so large we cannot safely index bits in a\nblock bitmap.(CVE-2024-46777)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: protect references to superblock parameters exposed in sysfs\r\n\r\nThe superblock buffers of nilfs2 can not only be overwritten at runtime\nfor modifications/repairs, but they are also regularly swapped, replaced\nduring resizing, and even abandoned when degrading to one side due to\nbacking device issues.  So, accessing them requires mutual exclusion using\nthe reader/writer semaphore \u0026quot;nilfs-\u0026gt;ns_sem\u0026quot;.\r\n\r\nSome sysfs attribute show methods read this superblock buffer without the\nnecessary mutual exclusion, which can cause problems with pointer\ndereferencing and memory access, so fix it.(CVE-2024-46780)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix missing cleanup on rollforward recovery error\r\n\r\nIn an error injection test of a routine for mount-time recovery, KASAN\nfound a use-after-free bug.\r\n\r\nIt turned out that if data recovery was performed using partial logs\ncreated by dsync writes, but an error occurred before starting the log\nwriter to create a recovered checkpoint, the inodes whose data had been\nrecovered were left in the ns_dirty_files list of the nilfs object and\nwere not freed.\r\n\r\nFix this issue by cleaning up inodes that have read the recovery data if\nthe recovery routine fails midway before the log writer starts.(CVE-2024-46781)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open\r\n\r\nThe mcp251x_hw_wake() function is called with the mpc_lock mutex held and\ndisables the interrupt handler so that no interrupts can be processed while\nwaking the device. If an interrupt has already occurred then waiting for\nthe interrupt handler to complete will deadlock because it will be trying\nto acquire the same mutex.\r\n\r\nCPU0                           CPU1\n----                           ----\nmcp251x_open()\n mutex_lock(\u0026amp;priv-\u0026gt;mcp_lock)\n  request_threaded_irq()\n                               \u0026lt;interrupt\u0026gt;\n                               mcp251x_can_ist()\n                                mutex_lock(\u0026amp;priv-\u0026gt;mcp_lock)\n  mcp251x_hw_wake()\n   disable_irq() \u0026lt;-- deadlock\r\n\r\nUse disable_irq_nosync() instead because the interrupt handler does\neverything while holding the mutex so it doesn\u0026apos;t matter if it\u0026apos;s still\nrunning.(CVE-2024-46791)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: dapm: Fix UAF for snd_soc_pcm_runtime object\r\n\r\nWhen using kernel with the following extra config,\r\n\r\n  - CONFIG_KASAN=y\n  - CONFIG_KASAN_GENERIC=y\n  - CONFIG_KASAN_INLINE=y\n  - CONFIG_KASAN_VMALLOC=y\n  - CONFIG_FRAME_WARN=4096\r\n\r\nkernel detects that snd_pcm_suspend_all() access a freed\n\u0026apos;snd_soc_pcm_runtime\u0026apos; object when the system is suspended, which\nleads to a use-after-free bug:\r\n\r\n[   52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270\n[   52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330\r\n\r\n[   52.047785] Call trace:\n[   52.047787]  dump_backtrace+0x0/0x3c0\n[   52.047794]  show_stack+0x34/0x50\n[   52.047797]  dump_stack_lvl+0x68/0x8c\n[   52.047802]  print_address_description.constprop.0+0x74/0x2c0\n[   52.047809]  kasan_report+0x210/0x230\n[   52.047815]  __asan_report_load1_noabort+0x3c/0x50\n[   52.047820]  snd_pcm_suspend_all+0x1a8/0x270\n[   52.047824]  snd_soc_suspend+0x19c/0x4e0\r\n\r\nThe snd_pcm_sync_stop() has a NULL check on \u0026apos;substream-\u0026gt;runtime\u0026apos; before\nmaking any access. So we need to always set \u0026apos;substream-\u0026gt;runtime\u0026apos; to NULL\neverytime we kfree() it.(CVE-2024-46798)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Add array index check for hdcp ddc access\r\n\r\n[Why]\nCoverity reports OVERRUN warning. Do not check if array\nindex valid.\r\n\r\n[How]\nCheck msg_id valid and valid array index.(CVE-2024-46804)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check msg_id before processing transcation\r\n\r\n[WHY \u0026amp; HOW]\nHDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a valid\narray index, and it needs checking before used.\r\n\r\nThis fixes 4 OVERRUN issues reported by Coverity.(CVE-2024-46814)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links\r\n\r\n[Why]\nCoverity report OVERRUN warning. There are\nonly max_links elements within dc-\u0026gt;links. link\ncount could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31.\r\n\r\n[How]\nMake sure link count less than max_links.(CVE-2024-46816)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check gpio_id before used as array index\r\n\r\n[WHY \u0026amp; HOW]\nGPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore\nshould be checked in advance.\r\n\r\nThis fixes 5 OVERRUN issues reported by Coverity.(CVE-2024-46818)\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\nrtmutex: Drop rt_mutex::wait_lock before scheduling\r\n\r\nrt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held.  In the\ngood case it returns with the lock held and in the deadlock case it emits a\nwarning and goes into an endless scheduling loop with the lock held, which\ntriggers the \u0026apos;scheduling in atomic\u0026apos; warning.\r\n\r\nUnlock rt_mutex::wait_lock in the dead lock case before issuing the warning\nand dropping into the schedule for ever loop.\r\n\r\n[ tglx: Moved unlock before the WARN(), removed the pointless comment,\n  \tmassaged changelog, added Fixes tag ](CVE-2024-46829)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hns3: void array out of bound when loop tnl_num\r\n\r\nWhen query reg inf of SSU, it loops tnl_num times. However, tnl_num comes\nfrom hardware and the length of array is a fixed value. To void array out\nof bound, make sure the loop time is not greater than the length of array(CVE-2024-46833)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don\u0026apos;t BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()\r\n\r\nWe handle errors here properly, ENOMEM isn\u0026apos;t fatal, return the error.(CVE-2024-46841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\num: line: always fill *error_out in setup_one_line()\r\n\r\nThe pointer isn\u0026apos;t initialized by callers, but I have\nencountered cases where it\u0026apos;s still printed; initialize\nit in all possible cases in setup_one_line().(CVE-2024-46844)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: meson: axg-card: fix \u0026apos;use-after-free\u0026apos;\r\n\r\nBuffer \u0026apos;card-\u0026gt;dai_link\u0026apos; is reallocated in \u0026apos;meson_card_reallocate_links()\u0026apos;,\nso move \u0026apos;pad\u0026apos; pointer initialization after this function when memory is\nalready reallocated.\r\n\r\nKasan bug report:\r\n\r\n==================================================================\nBUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc\nRead of size 8 at addr ffff000000e8b260 by task modprobe/356\r\n\r\nCPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1\nCall trace:\n dump_backtrace+0x94/0xec\n show_stack+0x18/0x24\n dump_stack_lvl+0x78/0x90\n print_report+0xfc/0x5c0\n kasan_report+0xb8/0xfc\n __asan_load8+0x9c/0xb8\n axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card]\n meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils]\n platform_probe+0x8c/0xf4\n really_probe+0x110/0x39c\n __driver_probe_device+0xb8/0x18c\n driver_probe_device+0x108/0x1d8\n __driver_attach+0xd0/0x25c\n bus_for_each_dev+0xe0/0x154\n driver_attach+0x34/0x44\n bus_add_driver+0x134/0x294\n driver_register+0xa8/0x1e8\n __platform_driver_register+0x44/0x54\n axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card]\n do_one_initcall+0xdc/0x25c\n do_init_module+0x10c/0x334\n load_module+0x24c4/0x26cc\n init_module_from_file+0xd4/0x128\n __arm64_sys_finit_module+0x1f4/0x41c\n invoke_syscall+0x60/0x188\n el0_svc_common.constprop.0+0x78/0x13c\n do_el0_svc+0x30/0x40\n el0_svc+0x38/0x78\n el0t_64_sync_handler+0x100/0x12c\n el0t_64_sync+0x190/0x194(CVE-2024-46849)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Fix bridge mode operations when there are no VFs\r\n\r\nCurrently, trying to set the bridge mode attribute when numvfs=0 leads to a\ncrash:\r\n\r\nbridge link set dev eth2 hwmode vepa\r\n\r\n[  168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030\n[...]\n[  168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core]\n[...]\n[  168.976037] Call Trace:\n[  168.976188]  \u0026lt;TASK\u0026gt;\n[  168.978620]  _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core]\n[  168.979074]  mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core]\n[  168.979471]  rtnl_bridge_setlink+0xe9/0x1f0\n[  168.979714]  rtnetlink_rcv_msg+0x159/0x400\n[  168.980451]  netlink_rcv_skb+0x54/0x100\n[  168.980675]  netlink_unicast+0x241/0x360\n[  168.980918]  netlink_sendmsg+0x1f6/0x430\n[  168.981162]  ____sys_sendmsg+0x3bb/0x3f0\n[  168.982155]  ___sys_sendmsg+0x88/0xd0\n[  168.985036]  __sys_sendmsg+0x59/0xa0\n[  168.985477]  do_syscall_64+0x79/0x150\n[  168.987273]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  168.987773] RIP: 0033:0x7f8f7950f917\r\n\r\n(esw-\u0026gt;fdb_table.legacy.vepa_fdb is null)\r\n\r\nThe bridge mode is only relevant when there are multiple functions per\nport. Therefore, prevent setting and getting this setting when there are no\nVFs.\r\n\r\nNote that after this change, there are no settings to change on the PF\ninterface using `bridge link` when there are no VFs, so the interface no\nlonger appears in the `bridge link` output.(CVE-2024-46857)",
  "id": "OESA-2024-2220",
  "modified": "2026-08-06T11:07:41Z",
  "published": "2024-10-12T11:07:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2220"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39482"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41030"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41095"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43900"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44958"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44982"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45008"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45016"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46673"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46674"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46679"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46681"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46695"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46707"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46721"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46725"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46726"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46732"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46737"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46738"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46739"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46740"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46743"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46750"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46753"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46755"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46756"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46758"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46759"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46761"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46771"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46777"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46780"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46781"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46791"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46798"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46804"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46814"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46816"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46818"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46821"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46829"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46833"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46841"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46844"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46849"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46857"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-39482",
    "CVE-2024-41030",
    "CVE-2024-41095",
    "CVE-2024-43900",
    "CVE-2024-44958",
    "CVE-2024-44982",
    "CVE-2024-45008",
    "CVE-2024-45016",
    "CVE-2024-46673",
    "CVE-2024-46674",
    "CVE-2024-46679",
    "CVE-2024-46681",
    "CVE-2024-46695",
    "CVE-2024-46707",
    "CVE-2024-46721",
    "CVE-2024-46725",
    "CVE-2024-46726",
    "CVE-2024-46732",
    "CVE-2024-46737",
    "CVE-2024-46738",
    "CVE-2024-46739",
    "CVE-2024-46740",
    "CVE-2024-46743",
    "CVE-2024-46750",
    "CVE-2024-46753",
    "CVE-2024-46755",
    "CVE-2024-46756",
    "CVE-2024-46758",
    "CVE-2024-46759",
    "CVE-2024-46761",
    "CVE-2024-46771",
    "CVE-2024-46777",
    "CVE-2024-46780",
    "CVE-2024-46781",
    "CVE-2024-46791",
    "CVE-2024-46798",
    "CVE-2024-46804",
    "CVE-2024-46814",
    "CVE-2024-46816",
    "CVE-2024-46818",
    "CVE-2024-46821",
    "CVE-2024-46829",
    "CVE-2024-46833",
    "CVE-2024-46841",
    "CVE-2024-46844",
    "CVE-2024-46849",
    "CVE-2024-46857"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-48.0.0.53.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-48.0.0.53.oe2403.aarch64.rpm",
          "kernel-6.6.0-48.0.0.53.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-48.0.0.53.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-48.0.0.53.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-48.0.0.53.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-48.0.0.53.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-48.0.0.53.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-48.0.0.53.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-48.0.0.53.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-48.0.0.53.oe2403.aarch64.rpm",
          "perf-6.6.0-48.0.0.53.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-48.0.0.53.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-48.0.0.53.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-48.0.0.53.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-48.0.0.53.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-48.0.0.53.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-48.0.0.53.oe2403.x86_64.rpm",
          "kernel-6.6.0-48.0.0.53.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-48.0.0.53.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-48.0.0.53.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-48.0.0.53.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-48.0.0.53.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-48.0.0.53.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-48.0.0.53.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-48.0.0.53.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-48.0.0.53.oe2403.x86_64.rpm",
          "perf-6.6.0-48.0.0.53.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-48.0.0.53.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-48.0.0.53.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-48.0.0.53.oe2403.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-48.0.0.53.oe2403"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "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:  ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()  The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.(CVE-2023-52917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: pci: cx23885: check cx23885_vdev_init() return  cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check.  Add a NULL pointer check and go to the error unwind if it is NULL.(CVE-2023-52918)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: make sure that WRITTEN is set on all metadata blocks\r\n\r\nWe previously would call btrfs_check_leaf() if we had the check\nintegrity code enabled, which meant that we could only run the extended\nleaf checks if we had WRITTEN set on the header flags.\r\n\r\nThis leaves a gap in our checking, because we could end up with\ncorruption on disk where WRITTEN isn\u0026apos;t set on the leaf, and then the\nextended leaf checks don\u0026apos;t get run which we rely on to validate all of\nthe item pointers to make sure we don\u0026apos;t access memory outside of the\nextent buffer.\r\n\r\nHowever, since 732fab95abe2 (\u0026quot;btrfs: check-integrity: remove\nCONFIG_BTRFS_FS_CHECK_INTEGRITY option\u0026quot;) we no longer call\nbtrfs_check_leaf() from btrfs_mark_buffer_dirty(), which means we only\never call it on blocks that are being written out, and thus have WRITTEN\nset, or that are being read in, which should have WRITTEN set.\r\n\r\nAdd checks to make sure we have WRITTEN set appropriately, and then make\nsure __btrfs_check_leaf() always does the item checking.  This will\nprotect us from file systems that have been corrupted and no longer have\nWRITTEN set on some of the blocks.\r\n\r\nThis was hit on a crafted image tweaking the WRITTEN bit and reported by\nKASAN as out-of-bound access in the eb accessors. The example is a dir\nitem at the end of an eb.\r\n\r\n  [2.042] BTRFS warning (device loop1): bad eb member start: ptr 0x3fff start 30572544 member offset 16410 size 2\n  [2.040] general protection fault, probably for non-canonical address 0xe0009d1000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI\n  [2.537] KASAN: maybe wild-memory-access in range [0x0005088000000018-0x000508800000001f]\n  [2.729] CPU: 0 PID: 2587 Comm: mount Not tainted 6.8.2 #1\n  [2.729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n  [2.621] RIP: 0010:btrfs_get_16+0x34b/0x6d0\n  [2.621] RSP: 0018:ffff88810871fab8 EFLAGS: 00000206\n  [2.621] RAX: 0000a11000000003 RBX: ffff888104ff8720 RCX: ffff88811b2288c0\n  [2.621] RDX: dffffc0000000000 RSI: ffffffff81dd8aca RDI: ffff88810871f748\n  [2.621] RBP: 000000000000401a R08: 0000000000000001 R09: ffffed10210e3ee9\n  [2.621] R10: ffff88810871f74f R11: 205d323430333737 R12: 000000000000001a\n  [2.621] R13: 000508800000001a R14: 1ffff110210e3f5d R15: ffffffff850011e8\n  [2.621] FS:  00007f56ea275840(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000\n  [2.621] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  [2.621] CR2: 00007febd13b75c0 CR3: 000000010bb50000 CR4: 00000000000006f0\n  [2.621] Call Trace:\n  [2.621]  \u0026lt;TASK\u0026gt;\n  [2.621]  ? show_regs+0x74/0x80\n  [2.621]  ? die_addr+0x46/0xc0\n  [2.621]  ? exc_general_protection+0x161/0x2a0\n  [2.621]  ? asm_exc_general_protection+0x26/0x30\n  [2.621]  ? btrfs_get_16+0x33a/0x6d0\n  [2.621]  ? btrfs_get_16+0x34b/0x6d0\n  [2.621]  ? btrfs_get_16+0x33a/0x6d0\n  [2.621]  ? __pfx_btrfs_get_16+0x10/0x10\n  [2.621]  ? __pfx_mutex_unlock+0x10/0x10\n  [2.621]  btrfs_match_dir_item_name+0x101/0x1a0\n  [2.621]  btrfs_lookup_dir_item+0x1f3/0x280\n  [2.621]  ? __pfx_btrfs_lookup_dir_item+0x10/0x10\n  [2.621]  btrfs_get_tree+0xd25/0x1910\r\n\r\n[ copy more details from report ](CVE-2024-35949)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: ISO: Fix not validating setsockopt user input\r\n\r\nCheck user input length before copying data.(CVE-2024-35964)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niommu/arm-smmu: Use the correct type in nvidia_smmu_context_fault()\r\n\r\nThis was missed because of the function pointer indirection.\r\n\r\nnvidia_smmu_context_fault() is also installed as a irq function, and the\n\u0026apos;void *\u0026apos; was changed to a struct arm_smmu_domain. Since the iommu_domain\nis embedded at a non-zero offset this causes nvidia_smmu_context_fault()\nto miscompute the offset. Fixup the types.\r\n\r\n  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000120\n  Mem abort info:\n    ESR = 0x0000000096000004\n    EC = 0x25: DABT (current EL), IL = 32 bits\n    SET = 0, FnV = 0\n    EA = 0, S1PTW = 0\n    FSC = 0x04: level 0 translation fault\n  Data abort info:\n    ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n    CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n    GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n  user pgtable: 4k pages, 48-bit VAs, pgdp=0000000107c9f000\n  [0000000000000120] pgd=0000000000000000, p4d=0000000000000000\n  Internal error: Oops: 0000000096000004 [#1] SMP\n  Modules linked in:\n  CPU: 1 PID: 47 Comm: kworker/u25:0 Not tainted 6.9.0-0.rc7.58.eln136.aarch64 #1\n  Hardware name: Unknown NVIDIA Jetson Orin NX/NVIDIA Jetson Orin NX, BIOS 3.1-32827747 03/19/2023\n  Workqueue: events_unbound deferred_probe_work_func\n  pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : nvidia_smmu_context_fault+0x1c/0x158\n  lr : __free_irq+0x1d4/0x2e8\n  sp : ffff80008044b6f0\n  x29: ffff80008044b6f0 x28: ffff000080a60b18 x27: ffffd32b5172e970\n  x26: 0000000000000000 x25: ffff0000802f5aac x24: ffff0000802f5a30\n  x23: ffff0000802f5b60 x22: 0000000000000057 x21: 0000000000000000\n  x20: ffff0000802f5a00 x19: ffff000087d4cd80 x18: ffffffffffffffff\n  x17: 6234362066666666 x16: 6630303078302d30 x15: ffff00008156d888\n  x14: 0000000000000000 x13: ffff0000801db910 x12: ffff00008156d6d0\n  x11: 0000000000000003 x10: ffff0000801db918 x9 : ffffd32b50f94d9c\n  x8 : 1fffe0001032fda1 x7 : ffff00008197ed00 x6 : 000000000000000f\n  x5 : 000000000000010e x4 : 000000000000010e x3 : 0000000000000000\n  x2 : ffffd32b51720cd8 x1 : ffff000087e6f700 x0 : 0000000000000057\n  Call trace:\n   nvidia_smmu_context_fault+0x1c/0x158\n   __free_irq+0x1d4/0x2e8\n   free_irq+0x3c/0x80\n   devm_free_irq+0x64/0xa8\n   arm_smmu_domain_free+0xc4/0x158\n   iommu_domain_free+0x44/0xa0\n   iommu_deinit_device+0xd0/0xf8\n   __iommu_group_remove_device+0xcc/0xe0\n   iommu_bus_notifier+0x64/0xa8\n   notifier_call_chain+0x78/0x148\n   blocking_notifier_call_chain+0x4c/0x90\n   bus_notify+0x44/0x70\n   device_del+0x264/0x3e8\n   pci_remove_bus_device+0x84/0x120\n   pci_remove_root_bus+0x5c/0xc0\n   dw_pcie_host_deinit+0x38/0xe0\n   tegra_pcie_config_rp+0xc0/0x1f0\n   tegra_pcie_dw_probe+0x34c/0x700\n   platform_probe+0x70/0xe8\n   really_probe+0xc8/0x3a0\n   __driver_probe_device+0x84/0x160\n   driver_probe_device+0x44/0x130\n   __device_attach_driver+0xc4/0x170\n   bus_for_each_drv+0x90/0x100\n   __device_attach+0xa8/0x1c8\n   device_initial_probe+0x1c/0x30\n   bus_probe_device+0xb0/0xc0\n   deferred_probe_work_func+0xbc/0x120\n   process_one_work+0x194/0x490\n   worker_thread+0x284/0x3b0\n   kthread+0xf4/0x108\n   ret_from_fork+0x10/0x20\n  Code: a9b97bfd 910003fd a9025bf5 f85a0035 (b94122a1)(CVE-2024-36884)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndev/parport: fix the array out-of-bounds risk\r\n\r\nFixed array out-of-bounds issues caused by sprintf\nby replacing it with snprintf for safer data copying,\nensuring the destination buffer is not overflowed.\r\n\r\nBelow is the stack trace I encountered during the actual issue:\r\n\r\n[ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector:\nKernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport]\n[ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm:\nQThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2\n[ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp\n[ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun\nPGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024\n[ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace:\n[ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0\n[ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20\n[ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c\n[ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc\n[ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38\n[ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport](CVE-2024-42301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: Fix array-index-out-of-bounds in diFree(CVE-2024-43858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau: prime: fix refcount underflow\r\n\r\nCalling nouveau_bo_ref() on a nouveau_bo without initializing it (and\nhence the backing ttm_bo) leads to a refcount underflow.\r\n\r\nInstead of calling nouveau_bo_ref() in the unwind path of\ndrm_gem_object_init(), clean things up manually.\r\n\r\n(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)(CVE-2024-43867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndevres: Fix memory leakage caused by driver API devm_free_percpu()\r\n\r\nIt will cause memory leakage when use driver API devm_free_percpu()\nto free memory allocated by devm_alloc_percpu(), fixed by using\ndevres_release() instead of devres_destroy() within devm_free_percpu().(CVE-2024-43871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/msm/dpu: cleanup FB if dpu_format_populate_layout fails\r\n\r\nIf the dpu_format_populate_layout() fails, then FB is prepared, but not\ncleaned up. This ends up leaking the pin_count on the GEM object and\ncauses a splat during DRM file closure:\r\n\r\nmsm_obj-\u0026gt;pin_count\nWARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc\n[...]\nCall trace:\n update_lru_locked+0xc4/0xcc\n put_pages+0xac/0x100\n msm_gem_free_object+0x138/0x180\n drm_gem_object_free+0x1c/0x30\n drm_gem_object_handle_put_unlocked+0x108/0x10c\n drm_gem_object_release_handle+0x58/0x70\n idr_for_each+0x68/0xec\n drm_gem_release+0x28/0x40\n drm_file_free+0x174/0x234\n drm_release+0xb0/0x160\n __fput+0xc0/0x2c8\n __fput_sync+0x50/0x5c\n __arm64_sys_close+0x38/0x7c\n invoke_syscall+0x48/0x118\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x4c/0x120\n el0t_64_sync_handler+0x100/0x12c\n el0t_64_sync+0x190/0x194\nirq event stamp: 129818\nhardirqs last  enabled at (129817): [\u0026lt;ffffa5f6d953fcc0\u0026gt;] console_unlock+0x118/0x124\nhardirqs last disabled at (129818): [\u0026lt;ffffa5f6da7dcf04\u0026gt;] el1_dbg+0x24/0x8c\nsoftirqs last  enabled at (129808): [\u0026lt;ffffa5f6d94afc18\u0026gt;] handle_softirqs+0x4c8/0x4e8\nsoftirqs last disabled at (129785): [\u0026lt;ffffa5f6d94105e4\u0026gt;] __do_softirq+0x14/0x20\r\n\r\nPatchwork: https://patchwork.freedesktop.org/patch/600714/(CVE-2024-44982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: ethernet: mtk_wed: fix use-after-free panic in mtk_wed_setup_tc_block_cb()\r\n\r\nWhen there are multiple ap interfaces on one band and with WED on,\nturning the interface down will cause a kernel panic on MT798X.\r\n\r\nPreviously, cb_priv was freed in mtk_wed_setup_tc_block() without\nmarking NULL,and mtk_wed_setup_tc_block_cb() didn\u0026apos;t check the value, too.\r\n\r\nAssign NULL after free cb_priv in mtk_wed_setup_tc_block() and check NULL\nin mtk_wed_setup_tc_block_cb().\r\n\r\n----------\nUnable to handle kernel paging request at virtual address 0072460bca32b4f5\nCall trace:\n mtk_wed_setup_tc_block_cb+0x4/0x38\n 0xffffffc0794084bc\n tcf_block_playback_offloads+0x70/0x1e8\n tcf_block_unbind+0x6c/0xc8\n...\n---------(CVE-2024-44997)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: core: Prevent USB core invalid event buffer address access\r\n\r\nThis commit addresses an issue where the USB core could access an\ninvalid event buffer address during runtime suspend, potentially causing\nSMMU faults and other memory issues in Exynos platforms. The problem\narises from the following sequence.\n        1. In dwc3_gadget_suspend, there is a chance of a timeout when\n        moving the USB core to the halt state after clearing the\n        run/stop bit by software.\n        2. In dwc3_core_exit, the event buffer is cleared regardless of\n        the USB core\u0026apos;s status, which may lead to an SMMU faults and\n        other memory issues. if the USB core tries to access the event\n        buffer address.\r\n\r\nTo prevent this hardware quirk on Exynos platforms, this commit ensures\nthat the event buffer address is not cleared by software  when the USB\ncore is active during runtime suspend by checking its status before\nclearing the buffer address.(CVE-2024-46675)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngtp: fix a potential NULL pointer dereference\r\n\r\nWhen sockfd_lookup() fails, gtp_encap_enable_socket() returns a\nNULL pointer, but its callers only check for error pointers thus miss\nthe NULL pointer case.\r\n\r\nFix it by returning an error pointer with the error code carried from\nsockfd_lookup().\r\n\r\n(I found this bug during code inspection.)(CVE-2024-46677)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number\r\n\r\nCheck the fb_channel_number range to avoid the array out-of-bounds\nread error(CVE-2024-46724)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nBluetooth: btnxpuart: Fix Null pointer dereference in btnxpuart_flush()\r\n\r\nThis adds a check before freeing the rx-\u0026gt;skb in flush and close\nfunctions to handle the kernel crash seen while removing driver after FW\ndownload fails or before FW download completes.\r\n\r\ndmesg log:\n[   54.634586] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080\n[   54.643398] Mem abort info:\n[   54.646204]   ESR = 0x0000000096000004\n[   54.649964]   EC = 0x25: DABT (current EL), IL = 32 bits\n[   54.655286]   SET = 0, FnV = 0\n[   54.658348]   EA = 0, S1PTW = 0\n[   54.661498]   FSC = 0x04: level 0 translation fault\n[   54.666391] Data abort info:\n[   54.669273]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[   54.674768]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[   54.674771]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[   54.674775] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000048860000\n[   54.674780] [0000000000000080] pgd=0000000000000000, p4d=0000000000000000\n[   54.703880] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[   54.710152] Modules linked in: btnxpuart(-) overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_micfil snd_soc_fsl_spdif snd_soc_fsl_sai snd_soc_fsl_utils imx_pcm_dma gpio_ir_recv rc_core sch_fq_codel fuse\n[   54.744357] CPU: 3 PID: 72 Comm: kworker/u9:0 Not tainted 6.6.3-otbr-g128004619037 #2\n[   54.744364] Hardware name: FSL i.MX8MM EVK board (DT)\n[   54.744368] Workqueue: hci0 hci_power_on\n[   54.757244] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   54.757249] pc : kfree_skb_reason+0x18/0xb0\n[   54.772299] lr : btnxpuart_flush+0x40/0x58 [btnxpuart]\n[   54.782921] sp : ffff8000805ebca0\n[   54.782923] x29: ffff8000805ebca0 x28: ffffa5c6cf1869c0 x27: ffffa5c6cf186000\n[   54.782931] x26: ffff377b84852400 x25: ffff377b848523c0 x24: ffff377b845e7230\n[   54.782938] x23: ffffa5c6ce8dbe08 x22: ffffa5c6ceb65410 x21: 00000000ffffff92\n[   54.782945] x20: ffffa5c6ce8dbe98 x19: ffffffffffffffac x18: ffffffffffffffff\n[   54.807651] x17: 0000000000000000 x16: ffffa5c6ce2824ec x15: ffff8001005eb857\n[   54.821917] x14: 0000000000000000 x13: ffffa5c6cf1a02e0 x12: 0000000000000642\n[   54.821924] x11: 0000000000000040 x10: ffffa5c6cf19d690 x9 : ffffa5c6cf19d688\n[   54.821931] x8 : ffff377b86000028 x7 : 0000000000000000 x6 : 0000000000000000\n[   54.821938] x5 : ffff377b86000000 x4 : 0000000000000000 x3 : 0000000000000000\n[   54.843331] x2 : 0000000000000000 x1 : 0000000000000002 x0 : ffffffffffffffac\n[   54.857599] Call trace:\n[   54.857601]  kfree_skb_reason+0x18/0xb0\n[   54.863878]  btnxpuart_flush+0x40/0x58 [btnxpuart]\n[   54.863888]  hci_dev_open_sync+0x3a8/0xa04\n[   54.872773]  hci_power_on+0x54/0x2e4\n[   54.881832]  process_one_work+0x138/0x260\n[   54.881842]  worker_thread+0x32c/0x438\n[   54.881847]  kthread+0x118/0x11c\n[   54.881853]  ret_from_fork+0x10/0x20\n[   54.896406] Code: a9be7bfd 910003fd f9000bf3 aa0003f3 (b940d400)\n[   54.896410] ---[ end trace 0000000000000000 ]---(CVE-2024-46749)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (nct6775-core) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Validate function returns\r\n\r\n[WHAT \u0026amp; HOW]\nFunction return values must be checked before data can be used\nin subsequent functions.\r\n\r\nThis fixes 4 CHECKED_RETURN issues reported by Coverity.(CVE-2024-46775)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nila: call nf_unregister_net_hooks() sooner\r\n\r\nsyzbot found an use-after-free Read in ila_nf_input [1]\r\n\r\nIssue here is that ila_xlat_exit_net() frees the rhashtable,\nthen call nf_unregister_net_hooks().\r\n\r\nIt should be done in the reverse way, with a synchronize_rcu().\r\n\r\nThis is a good match for a pre_exit() method.\r\n\r\n[1]\n BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]\n BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline]\n BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline]\n BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672\nRead of size 4 at addr ffff888064620008 by task ksoftirqd/0/16\r\n\r\nCPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  __dump_stack lib/dump_stack.c:93 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119\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  rht_key_hashfn include/linux/rhashtable.h:159 [inline]\n  __rhashtable_lookup include/linux/rhashtable.h:604 [inline]\n  rhashtable_lookup include/linux/rhashtable.h:646 [inline]\n  rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672\n  ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline]\n  ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]\n  ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190\n  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n  nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626\n  nf_hook include/linux/netfilter.h:269 [inline]\n  NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312\n  __netif_receive_skb_one_core net/core/dev.c:5661 [inline]\n  __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775\n  process_backlog+0x662/0x15b0 net/core/dev.c:6108\n  __napi_poll+0xcb/0x490 net/core/dev.c:6772\n  napi_poll net/core/dev.c:6841 [inline]\n  net_rx_action+0x89b/0x1240 net/core/dev.c:6963\n  handle_softirqs+0x2c4/0x970 kernel/softirq.c:554\n  run_ksoftirqd+0xca/0x130 kernel/softirq.c:928\n  smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164\n  kthread+0x2f0/0x390 kernel/kthread.c:389\n  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;\r\n\r\nThe buggy address belongs to the physical page:\npage: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620\nflags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)\npage_type: 0xbfffffff(buddy)\nraw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000\nraw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000\npage dumped because: kasan: bad access detected\npage_owner tracks the page as freed\npage last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187\n  set_page_owner include/linux/page_owner.h:32 [inline]\n  post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493\n  prep_new_page mm/page_alloc.c:1501 [inline]\n  get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439\n  __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695\n  __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]\n  alloc_pages_node_noprof include/linux/gfp.h:296 [inline]\n  ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103\n  __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130\n  __do_kmalloc_node mm/slub.c:4146 [inline]\n  __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164\n  __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650\n  bucket_table_alloc lib/rhashtable.c:186 [inline]\n  rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071\n  ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613\n  ops_ini\n---truncated---(CVE-2024-46782)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: added NULL check at start of dc_validate_stream\r\n\r\n[Why]\nprevent invalid memory access\r\n\r\n[How]\ncheck if dc and stream are NULL(CVE-2024-46802)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: nxp-fspi: fix the KASAN report out-of-bounds bug\r\n\r\nChange the memcpy length to fix the out-of-bounds issue when writing the\ndata that is not 4 byte aligned to TX FIFO.\r\n\r\nTo reproduce the issue, write 3 bytes data to NOR chip.\r\n\r\ndd if=3b of=/dev/mtd0\n[   36.926103] ==================================================================\n[   36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838\n[   36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455\n[   36.946721]\n[   36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070\n[   36.956185] Hardware name: Freescale i.MX8QM MEK (DT)\n[   36.961260] Call trace:\n[   36.963723]  dump_backtrace+0x90/0xe8\n[   36.967414]  show_stack+0x18/0x24\n[   36.970749]  dump_stack_lvl+0x78/0x90\n[   36.974451]  print_report+0x114/0x5cc\n[   36.978151]  kasan_report+0xa4/0xf0\n[   36.981670]  __asan_report_load_n_noabort+0x1c/0x28\n[   36.986587]  nxp_fspi_exec_op+0x26ec/0x2838\n[   36.990800]  spi_mem_exec_op+0x8ec/0xd30\n[   36.994762]  spi_mem_no_dirmap_read+0x190/0x1e0\n[   36.999323]  spi_mem_dirmap_write+0x238/0x32c\n[   37.003710]  spi_nor_write_data+0x220/0x374\n[   37.007932]  spi_nor_write+0x110/0x2e8\n[   37.011711]  mtd_write_oob_std+0x154/0x1f0\n[   37.015838]  mtd_write_oob+0x104/0x1d0\n[   37.019617]  mtd_write+0xb8/0x12c\n[   37.022953]  mtdchar_write+0x224/0x47c\n[   37.026732]  vfs_write+0x1e4/0x8c8\n[   37.030163]  ksys_write+0xec/0x1d0\n[   37.033586]  __arm64_sys_write+0x6c/0x9c\n[   37.037539]  invoke_syscall+0x6c/0x258\n[   37.041327]  el0_svc_common.constprop.0+0x160/0x22c\n[   37.046244]  do_el0_svc+0x44/0x5c\n[   37.049589]  el0_svc+0x38/0x78\n[   37.052681]  el0t_64_sync_handler+0x13c/0x158\n[   37.057077]  el0t_64_sync+0x190/0x194\n[   37.060775]\n[   37.062274] Allocated by task 455:\n[   37.065701]  kasan_save_stack+0x2c/0x54\n[   37.069570]  kasan_save_track+0x20/0x3c\n[   37.073438]  kasan_save_alloc_info+0x40/0x54\n[   37.077736]  __kasan_kmalloc+0xa0/0xb8\n[   37.081515]  __kmalloc_noprof+0x158/0x2f8\n[   37.085563]  mtd_kmalloc_up_to+0x120/0x154\n[   37.089690]  mtdchar_write+0x130/0x47c\n[   37.093469]  vfs_write+0x1e4/0x8c8\n[   37.096901]  ksys_write+0xec/0x1d0\n[   37.100332]  __arm64_sys_write+0x6c/0x9c\n[   37.104287]  invoke_syscall+0x6c/0x258\n[   37.108064]  el0_svc_common.constprop.0+0x160/0x22c\n[   37.112972]  do_el0_svc+0x44/0x5c\n[   37.116319]  el0_svc+0x38/0x78\n[   37.119401]  el0t_64_sync_handler+0x13c/0x158\n[   37.123788]  el0t_64_sync+0x190/0x194\n[   37.127474]\n[   37.128977] The buggy address belongs to the object at ffff00081037c2a0\n[   37.128977]  which belongs to the cache kmalloc-8 of size 8\n[   37.141177] The buggy address is located 0 bytes inside of\n[   37.141177]  allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)\n[   37.153465]\n[   37.154971] The buggy address belongs to the physical page:\n[   37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c\n[   37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)\n[   37.175149] page_type: 0xfdffffff(slab)\n[   37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000\n[   37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000\n[   37.194553] page dumped because: kasan: bad access detected\n[   37.200144]\n[   37.201647] Memory state around the buggy address:\n[   37.206460]  ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc\n[   37.213701]  ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc\n[   37.220946] \u0026gt;ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc\n[   37.228186]                                ^\n[   37.232473]  ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[   37.239718]  ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n[   37.246962] ==============================================================\n---truncated---(CVE-2024-46853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX\r\n\r\n[Why \u0026amp; How]\nIt actually exposes \u0026apos;6\u0026apos; types in enum dmub_notification_type. Not 5. Using smaller\nnumber to create array dmub_callback \u0026amp; dmub_thread_offload has potential to access\nitem out of array bound. Fix it.(CVE-2024-46871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmack: tcp: ipv4, fix incorrect labeling\r\n\r\nCurrently, Smack mirrors the label of incoming tcp/ipv4 connections:\nwhen a label \u0026apos;foo\u0026apos; connects to a label \u0026apos;bar\u0026apos; with tcp/ipv4,\n\u0026apos;foo\u0026apos; always gets \u0026apos;foo\u0026apos; in returned ipv4 packets. So,\n1) returned packets are incorrectly labeled (\u0026apos;foo\u0026apos; instead of \u0026apos;bar\u0026apos;)\n2) \u0026apos;bar\u0026apos; can write to \u0026apos;foo\u0026apos; without being authorized to write.\r\n\r\nHere is a scenario how to see this:\r\n\r\n* Take two machines, let\u0026apos;s call them C and S,\n   with active Smack in the default state\n   (no settings, no rules, no labeled hosts, only builtin labels)\r\n\r\n* At S, add Smack rule \u0026apos;foo bar w\u0026apos;\n   (labels \u0026apos;foo\u0026apos; and \u0026apos;bar\u0026apos; are instantiated at S at this moment)\r\n\r\n* At S, at label \u0026apos;bar\u0026apos;, launch a program\n   that listens for incoming tcp/ipv4 connections\r\n\r\n* From C, at label \u0026apos;foo\u0026apos;, connect to the listener at S.\n   (label \u0026apos;foo\u0026apos; is instantiated at C at this moment)\n   Connection succeedes and works.\r\n\r\n* Send some data in both directions.\n* Collect network traffic of this connection.\r\n\r\nAll packets in both directions are labeled with the CIPSO\nof the label \u0026apos;foo\u0026apos;. Hence, label \u0026apos;bar\u0026apos; writes to \u0026apos;foo\u0026apos; without\nbeing authorized, and even without ever being known at C.\r\n\r\nIf anybody cares: exactly the same happens with DCCP.\r\n\r\nThis behavior 1st manifested in release 2.6.29.4 (see Fixes below)\nand it looks unintentional. At least, no explanation was provided.\r\n\r\nI changed returned packes label into the \u0026apos;bar\u0026apos;,\nto bring it into line with the Smack documentation claims.(CVE-2024-47659)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfsnotify: clear PARENT_WATCHED flags lazily\r\n\r\nIn some setups directories can have many (usually negative) dentries.\nHence __fsnotify_update_child_dentry_flags() function can take a\nsignificant amount of time. Since the bulk of this function happens\nunder inode-\u0026gt;i_lock this causes a significant contention on the lock\nwhen we remove the watch from the directory as the\n__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()\nraces with __fsnotify_update_child_dentry_flags() calls from\n__fsnotify_parent() happening on children. This can lead upto softlockup\nreports reported by users.\r\n\r\nFix the problem by calling fsnotify_update_children_dentry_flags() to\nset PARENT_WATCHED flags only when parent starts watching children.\r\n\r\nWhen parent stops watching children, clear false positive PARENT_WATCHED\nflags lazily in __fsnotify_parent() for each accessed child.(CVE-2024-47660)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Avoid overflow from uint32_t to uint8_t\r\n\r\n[WHAT \u0026amp; HOW]\ndmub_rb_cmd\u0026apos;s ramping_boundary has size of uint8_t and it is assigned\n0xFFFF. Fix it by changing it to uint8_t with value of 0xFF.\r\n\r\nThis fixes 2 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-47661)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0)\r\n\r\nErrata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0\n(SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an\ninbound PCIe TLP spans more than two internal AXI 128-byte bursts,\nthe bus may corrupt the packet payload and the corrupt data may\ncause associated applications or the processor to hang.\r\n\r\nThe workaround for Errata #i2037 is to limit the maximum read\nrequest size and maximum payload size to 128 bytes. Add workaround\nfor Errata #i2037 here.\r\n\r\nThe errata and workaround is applicable only to AM65x SR 1.0 and\nlater versions of the silicon will have this fixed.\r\n\r\n[1] -\u0026gt; https://www.ti.com/lit/er/sprz452i/sprz452i.pdf(CVE-2024-47667)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he  Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver.  Found by code review.(CVE-2024-47681)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Skip Recompute DSC Params if no Stream on Link  [why] Encounter NULL pointer dereference uner mst + dsc setup.  BUG: kernel NULL pointer dereference, address: 0000000000000008     PGD 0 P4D 0     Oops: 0000 [#1] PREEMPT SMP NOPTI     CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2     Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022     RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]     Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 \u0026lt;48\u0026gt; 8\u0026gt;     RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293     RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224     RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280     RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850     R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000     R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224     FS:  00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033     CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0     Call Trace: \u0026lt;TASK\u0026gt;      ? __die+0x23/0x70      ? page_fault_oops+0x171/0x4e0      ? plist_add+0xbe/0x100      ? exc_page_fault+0x7c/0x180      ? asm_exc_page_fault+0x26/0x30      ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]      ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]      compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]      ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]      compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]      amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]      drm_atomic_check_only+0x5c5/0xa40      drm_mode_atomic_ioctl+0x76e/0xbc0  [how] dsc recompute should be skipped if no mode change detected on the new request. If detected, keep checking whether the stream is already on current state or not.(CVE-2024-47683)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tcp: check skb is non-NULL in tcp_rto_delta_us()  We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases:  Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 \u0026lt;48\u0026gt; 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---(CVE-2024-47684)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()  syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th-\u0026gt;res1)  Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put()  BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255   nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255   nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344   nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310   __netif_receive_skb_one_core net/core/dev.c:5661 [inline]   __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775   process_backlog+0x4ad/0xa50 net/core/dev.c:6108   __napi_poll+0xe7/0x980 net/core/dev.c:6772   napi_poll net/core/dev.c:6841 [inline]   net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963   handle_softirqs+0x1ce/0x800 kernel/softirq.c:554   __do_softirq+0x14/0x1a kernel/softirq.c:588   do_softirq+0x9a/0x100 kernel/softirq.c:455   __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382   local_bh_enable include/linux/bottom_half.h:33 [inline]   rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline]   __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450   dev_queue_xmit include/linux/netdevice.h:3105 [inline]   neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565   neigh_output include/net/neighbour.h:542 [inline]   ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141   __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]   ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226   NF_HOOK_COND include/linux/netfilter.h:303 [inline]   ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247   dst_output include/net/dst.h:450 [inline]   NF_HOOK include/linux/netfilter.h:314 [inline]   ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366   inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135   __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466   tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]   tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143   tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333   __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679   inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750   __sys_connect_file net/socket.c:2061 [inline]   __sys_connect+0x606/0x690 net/socket.c:2078   __do_sys_connect net/socket.c:2088 [inline]   __se_sys_connect net/socket.c:2085 [inline]   __x64_sys_connect+0x91/0xe0 net/socket.c:2085   x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was stored to memory at:   nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249   nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344   nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48   expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]   nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288   nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626   nf_hook include/linux/netfilter.h:269 [inline]   NF_HOOK include/linux/netfilter.h:312 [inline]   ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310   __netif_receive_skb_one_core ---truncated---(CVE-2024-47685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to don\u0026apos;t set SB_RDONLY in f2fs_handle_critical_error()  syzbot reports a f2fs bug as below:  ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace:  percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42  destroy_super_work+0xec/0x130 fs/super.c:282  process_one_work kernel/workqueue.c:3231 [inline]  process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312  worker_thread+0x86d/0xd40 kernel/workqueue.c:3390  kthread+0x2f0/0x390 kernel/kthread.c:389  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244  As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb-\u0026gt;s_umount semaphore via remount procedure, then below race condition causes this bug:  - freeze_super()  - sb_wait_write(sb, SB_FREEZE_WRITE)  - sb_wait_write(sb, SB_FREEZE_PAGEFAULT)  - sb_wait_write(sb, SB_FREEZE_FS)      - f2fs_handle_critical_error       - sb-\u0026gt;s_flags |= SB_RDONLY - thaw_super  - thaw_super_locked   - sb_rdonly() is true, so it skips     sb_freeze_unlock(sb, SB_FREEZE_FS)   - deactivate_locked_super  Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let\u0026apos;s remove the logic and keep in line w/ ext4 [3].  [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz(CVE-2024-47689)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfsd: return -EINVAL when namelen is 0  When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered.  [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205]  dump_stack+0x9a/0xd0 [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  __kasan_report.cold+0x34/0x84 [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  kasan_report+0x3a/0x50 [ T1205]  nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  ? nfsd4_release_lockowner+0x410/0x410 [ T1205]  cld_pipe_downcall+0x5ca/0x760 [ T1205]  ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205]  ? down_write_killable_nested+0x170/0x170 [ T1205]  ? avc_policy_seqno+0x28/0x40 [ T1205]  ? selinux_file_permission+0x1b4/0x1e0 [ T1205]  rpc_pipe_write+0x84/0xb0 [ T1205]  vfs_write+0x143/0x520 [ T1205]  ksys_write+0xc9/0x170 [ T1205]  ? __ia32_sys_read+0x50/0x50 [ T1205]  ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205]  ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205]  do_syscall_64+0x33/0x40 [ T1205]  entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ==================================================================  Fix it by checking namelen.(CVE-2024-47692)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds  In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path-\u0026gt;s.con_num.  This commits resets the cid to clt_path-\u0026gt;s.con_num - 1, to stay in bounds in the cleanup loop later.(CVE-2024-47695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error  Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access.  dev-\u0026gt;filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index \u0026gt; 32 to index \u0026gt;= 32 to resolve this issue.  [hverkuil: added fixes tag, rtl2830_pid_filter -\u0026gt; rtl2832_pid_filter in logmsg](CVE-2024-47698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  can: bcm: Clear bo-\u0026gt;bcm_proc_read after remove_proc_entry().  syzbot reported a warning in bcm_release(). [0]  The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered.  However, if the socket is just close()d without the 2nd connect(), the remaining bo-\u0026gt;bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release().  Let\u0026apos;s clear bo-\u0026gt;bcm_proc_read after remove_proc_entry() in bcm_notify().  [0] name \u0026apos;4986\u0026apos; WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 \u0026lt;0f\u0026gt; 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS:  0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  \u0026lt;TASK\u0026gt;  bcm_release+0x250/0x880 net/can/bcm.c:1578  __sock_release net/socket.c:659 [inline]  sock_close+0xbc/0x240 net/socket.c:1421  __fput+0x24a/0x8a0 fs/file_table.c:422  task_work_run+0x24f/0x310 kernel/task_work.c:228  exit_task_work include/linux/task_work.h:40 [inline]  do_exit+0xa2f/0x27f0 kernel/exit.c:882  do_group_exit+0x207/0x2c0 kernel/exit.c:1031  __do_sys_exit_group kernel/exit.c:1042 [inline]  __se_sys_exit_group kernel/exit.c:1040 [inline]  __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040  x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160  \u0026lt;/TASK\u0026gt;(CVE-2024-47709)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  sock_map: Add a cond_resched() in sock_hash_free()  Several syzbot soft lockup reports all have in common sock_hash_free()  If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.(CVE-2024-47710)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func  This commit adds a null check for the set_output_gamma function pointer in the  dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null.  To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function.  This fix prevents a potential null pointer dereference error.  drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed \u0026apos;mpc-\u0026gt;funcs-\u0026gt;set_output_gamma\u0026apos; could be null (see line 386)  drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c     373 bool dcn30_set_output_transfer_func(struct dc *dc,     374                                 struct pipe_ctx *pipe_ctx,     375                                 const struct dc_stream_state *stream)     376 {     377         int mpcc_id = pipe_ctx-\u0026gt;plane_res.hubp-\u0026gt;inst;     378         struct mpc *mpc = pipe_ctx-\u0026gt;stream_res.opp-\u0026gt;ctx-\u0026gt;dc-\u0026gt;res_pool-\u0026gt;mpc;     379         const struct pwl_params *params = NULL;     380         bool ret = false;     381     382         /* program OGAM or 3DLUT only for the top pipe*/     383         if (pipe_ctx-\u0026gt;top_pipe == NULL) {     384                 /*program rmu shaper and 3dlut in MPC*/     385                 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream);     386                 if (ret == false \u0026amp;\u0026amp; mpc-\u0026gt;funcs-\u0026gt;set_output_gamma) {                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL      387                         if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_HWPWL)     388                                 params = \u0026amp;stream-\u0026gt;out_transfer_func.pwl;     389                         else if (pipe_ctx-\u0026gt;stream-\u0026gt;out_transfer_func.type ==     390                                         TF_TYPE_DISTRIBUTED_POINTS \u0026amp;\u0026amp;     391                                         cm3_helper_translate_curve_to_hw_format(     392                                         \u0026amp;stream-\u0026gt;out_transfer_func,     393                                         \u0026amp;mpc-\u0026gt;blender_params, false))     394                                 params = \u0026amp;mpc-\u0026gt;blender_params;     395                          /* there are no ROM LUTs in OUTGAM */     396                         if (stream-\u0026gt;out_transfer_func.type == TF_TYPE_PREDEFINED)     397                                 BREAK_TO_DEBUGGER();     398                 }     399         }     400 --\u0026gt; 401         mpc-\u0026gt;funcs-\u0026gt;set_output_gamma(mpc, mpcc_id, params);                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash      402         return ret;     403 }(CVE-2024-47720)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfsd: call cache_put if xdr_reserve_space returns NULL  If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get.  Reviwed-by: Jeff Layton \u0026lt;jlayton@kernel.org\u0026gt;(CVE-2024-47737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  KEYS: prevent NULL pointer dereference in find_asymmetric_key()  In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway.  Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks.  Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.(CVE-2024-47743)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix potential oob read in nilfs_btree_check_delete()  The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries.  This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself.  However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.(CVE-2024-47757)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nbd: fix race between timeout and normal completion  If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered.  Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd-\u0026gt;lock is grabbed for clearing the flag and the requeue.(CVE-2024-49855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tracing/timerlat: Fix a race during cpuhp processing  There is another found exception that the \u0026quot;timerlat/1\u0026quot; thread was scheduled on CPU0, and lead to timer corruption finally:  ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace:  \u0026lt;TASK\u0026gt;  ? __warn+0x7c/0x110  ? debug_print_object+0x7d/0xb0  ? report_bug+0xf1/0x1d0  ? prb_read_valid+0x17/0x20  ? handle_bug+0x3f/0x70  ? exc_invalid_op+0x13/0x60  ? asm_exc_invalid_op+0x16/0x20  ? debug_print_object+0x7d/0xb0  ? debug_print_object+0x7d/0xb0  ? __pfx_timerlat_irq+0x10/0x10  __debug_object_init+0x110/0x150  hrtimer_init+0x1d/0x60  timerlat_main+0xab/0x2d0  ? __pfx_timerlat_main+0x10/0x10  kthread+0xb7/0xe0  ? __pfx_kthread+0x10/0x10  ret_from_fork+0x2d/0x40  ? __pfx_kthread+0x10/0x10  ret_from_fork_asm+0x1a/0x30  \u0026lt;/TASK\u0026gt; ```  After tracing the scheduling event, it was discovered that the migration of the \u0026quot;timerlat/1\u0026quot; thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU:  T1                       | T2 [CPUHP_ONLINE]           | cpu_device_down() osnoise_hotplug_workfn() |                          |     cpus_write_lock()                          |     takedown_cpu(1)                          |     cpus_write_unlock() [CPUHP_OFFLINE]          |     cpus_read_lock()     |     start_kthread(1)     |     cpus_read_unlock()   |  To fix this, skip online processing if the CPU is already offline.(CVE-2024-49866)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: wait for fixup workers before stopping cleaner kthread during umount  During unmount, at close_ctree(), we have the following steps in this order:  1) Park the cleaner kthread - this doesn\u0026apos;t destroy the kthread, it basically    halts its execution (wake ups against it work but do nothing);  2) We stop the cleaner kthread - this results in freeing the respective    struct task_struct;  3) We call btrfs_stop_all_workers() which waits for any jobs running in all    the work queues and then free the work queues.  Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don\u0026apos;t wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources.  Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs.  The stack traces reported by syzbot were the following:    BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065   Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52    CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024   Workqueue: btrfs-fixup btrfs_work_helper   Call Trace:    \u0026lt;TASK\u0026gt;    __dump_stack lib/dump_stack.c:94 [inline]    dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120    print_address_description mm/kasan/report.c:377 [inline]    print_report+0x169/0x550 mm/kasan/report.c:488    kasan_report+0x143/0x180 mm/kasan/report.c:601    __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065    lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825    __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]    _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162    class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline]    try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154    btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842    btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314    process_one_work kernel/workqueue.c:3229 [inline]    process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310    worker_thread+0x870/0xd30 kernel/workqueue.c:3391    kthread+0x2f0/0x390 kernel/kthread.c:389    ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244    \u0026lt;/TASK\u0026gt;    Allocated by task 2:    kasan_save_stack mm/kasan/common.c:47 [inline]    kasan_save_track+0x3f/0x80 mm/kasan/common.c:68    unpoison_slab_object mm/kasan/common.c:319 [inline]    __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345    kasan_slab_alloc include/linux/kasan.h:247 [inline]    slab_post_alloc_hook mm/slub.c:4086 [inline]    slab_alloc_node mm/slub.c:4135 [inline]    kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187    alloc_task_struct_node kernel/fork.c:180 [inline]    dup_task_struct+0x57/0x8c0 kernel/fork.c:1107    copy_process+0x5d1/0x3d50 kernel/fork.c:2206    kernel_clone+0x223/0x880 kernel/fork.c:2787    kernel_thread+0x1bc/0x240 kernel/fork.c:2849    create_kthread kernel/kthread.c:412 [inline]    kthreadd+0x60d/0x810 kernel/kthread.c:765    ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244    Freed by task 61:    kasan_save_stack mm/kasan/common.c:47 [inline]    kasan_save_track+0x3f/0x80 mm/kasan/common.c:68    kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579    poison_slab_object mm/kasan/common.c:247 [inline]    __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264    kasan_slab_free include/linux/kasan.h:230 [inline]    slab_free_h ---truncated---(CVE-2024-49867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  btrfs: fix a NULL pointer dereference when failed to start a new trasacntion  [BUG] Syzbot reported a NULL pointer dereference with the following crash:    FAULT_INJECTION: forcing a failure.    start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676    prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642    relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678   ...   BTRFS info (device loop0): balance: ended with status: -12   Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI   KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667]   RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926   Call Trace:    \u0026lt;TASK\u0026gt;    commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496    btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430    del_balance_item fs/btrfs/volumes.c:3678 [inline]    reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742    btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574    btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673    vfs_ioctl fs/ioctl.c:51 [inline]    __do_sys_ioctl fs/ioctl.c:907 [inline]    __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893    do_syscall_x64 arch/x86/entry/common.c:52 [inline]    do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83    entry_SYSCALL_64_after_hwframe+0x77/0x7f  [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info-\u0026gt;balance_ctl to be NULL.  Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree.  However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume.  Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots().  That function checks if fs_info-\u0026gt;reloc_ctl is in the merge_reloc_tree stage, but since fs_info-\u0026gt;reloc_ctl is NULL, it results a NULL pointer dereference.  [FIX] Just add extra check on fs_info-\u0026gt;reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info-\u0026gt;reloc_ctl-\u0026gt;merge_reloc_tree.  That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.(CVE-2024-49868)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation  This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color  management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the  number of transfer function points (TRANSFER_FUNC_POINTS).  The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49895)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: Fix uninit-value access of new_ea in ea_buffer  syzbot reports that lzo1x_1_do_compress is using uninit-value:  ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178  ...  Uninit was stored to memory at:  ea_put fs/jfs/xattr.c:639 [inline]  ...  Local variable ea_buf created at:  __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662  __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934  =====================================================  The reason is ea_buf-\u0026gt;new_ea is not initialized properly.  Fix this by using memset to empty its content at the beginning in ea_get().(CVE-2024-49900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: check if leafidx greater than num leaves per dmap tree  syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.  Shaggy: Modified sanity check to apply to control pages as well as leaf pages.(CVE-2024-49902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: Fix uaf in dbFreeBits  [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216  CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0x169/0x550 mm/kasan/report.c:488  kasan_report+0x143/0x180 mm/kasan/report.c:601  __mutex_lock_common kernel/locking/mutex.c:587 [inline]  __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752  dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390  dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline]  dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409  dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650  jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100  jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  Freed by task 5218:  kasan_save_stack mm/kasan/common.c:47 [inline]  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68  kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579  poison_slab_object+0xe0/0x150 mm/kasan/common.c:240  __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256  kasan_slab_free include/linux/kasan.h:184 [inline]  slab_free_hook mm/slub.c:2252 [inline]  slab_free mm/slub.c:4473 [inline]  kfree+0x149/0x360 mm/slub.c:4594  dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278  jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247  jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454  reconfigure_super+0x445/0x880 fs/super.c:1083  vfs_cmd_reconfigure fs/fsopen.c:263 [inline]  vfs_fsconfig_locked fs/fsopen.c:292 [inline]  __do_sys_fsconfig fs/fsopen.c:473 [inline]  __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf.  Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.(CVE-2024-49903)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func  This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null.  To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.(CVE-2024-49911)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer  This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null.  The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed \u0026apos;head_pipe\u0026apos; could be null (see line 2681)(CVE-2024-49918)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer  This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null.  The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed \u0026apos;head_pipe\u0026apos; could be null (see line 1010)(CVE-2024-49919)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  x86/ioapic: Handle allocation failures gracefully  Breno observed panics when using failslab under certain conditions during runtime:     can not alloc irq_pin_list (-1,0,20)    Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed     panic+0x4e9/0x590    mp_irqdomain_alloc+0x9ab/0xa80    irq_domain_alloc_irqs_locked+0x25d/0x8d0    __irq_domain_alloc_irqs+0x80/0x110    mp_map_pin_to_irq+0x645/0x890    acpi_register_gsi_ioapic+0xe6/0x150    hpet_open+0x313/0x480  That\u0026apos;s a pointless panic which is a leftover of the historic IO/APIC code which panic\u0026apos;ed during early boot when the interrupt allocation failed.  The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode.  Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.(CVE-2024-49927)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: remove unreasonable unlock in ocfs2_read_blocks  Patch series \u0026quot;Misc fixes for ocfs2_read_blocks\u0026quot;, v5.  This series contains 2 fixes for ocfs2_read_blocks().  The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks().  The second patch fixes an issue reported by Heming Zhao when reviewing above fix.   This patch (of 2):  There was a lock release before exiting, so remove the unreasonable unlock.(CVE-2024-49965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index out of bounds in DCN30 color transformation  This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).  The fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the transfer function points. If \u0026apos;i\u0026apos; is out of bounds, the function returns false to indicate an error.  drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-49969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  NFSD: Limit the number of concurrent async COPY operations  Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector.  Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit.  An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy.  If there is need to make the mechanism more sophisticated, we can visit that in future patches.(CVE-2024-49974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tracing/timerlat: Drop interface_lock in stop_kthread()  stop_kthread() is the offline callback for \u0026quot;trace/osnoise:online\u0026quot;, since commit 5bfbcd1ee57b (\u0026quot;tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()\u0026quot;), the following ABBA deadlock scenario is introduced:  T1                            | T2 [BP]               | T3 [AP] osnoise_hotplug_workfn()      | work_for_cpu_fn()     | cpuhp_thread_fun()                               |   _cpu_down()         |   osnoise_cpu_die()   mutex_lock(\u0026amp;interface_lock) |                       |     stop_kthread()                               |     cpus_write_lock() |       mutex_lock(\u0026amp;interface_lock)   cpus_read_lock()            |     cpuhp_kick_ap()   |  As the interface_lock here in just for protecting the \u0026quot;kthread\u0026quot; field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.(CVE-2024-49976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume  In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.  This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks.  Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.(CVE-2024-49985)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ALSA: asihpi: Fix potential OOB array access  ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware.  We shouldn\u0026apos;t trust it blindly.  This patch adds a sanity check of the array index to fit in the array size.(CVE-2024-50007)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  cpufreq: Avoid a bad reference count on CPU node  In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented.  Address this by declaring the variable with the __free(device_node) cleanup attribute.(CVE-2024-50012)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()  On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog:  [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701]   ESR = 0x0000000096000007 [232066.588862]   EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084]   SET = 0, FnV = 0 [232066.589216]   EA = 0, S1PTW = 0 [232066.589340]   FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683]   ISV = 0, ISS = 0x00000007 [232066.589842]   CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052]  vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---(CVE-2024-50046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointer before dereferencing se  [WHAT \u0026amp; HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again.  This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-50049)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  usb: typec: tipd: Free IRQ only if it was requested before  In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client-\u0026gt;irq is set. This fixes the warning caused by the tps6598x module removal:  WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace:   devm_free_irq+0x80/0x8c   tps6598x_remove+0x28/0x88 [tps6598x]   i2c_device_remove+0x2c/0x9c   device_remove+0x4c/0x80   device_release_driver_internal+0x1cc/0x228   driver_detach+0x50/0x98   bus_remove_driver+0x6c/0xbc   driver_unregister+0x30/0x60   i2c_del_driver+0x54/0x64   tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x]   __arm64_sys_delete_module+0x184/0x264   invoke_syscall+0x48/0x110   el0_svc_common.constprop.0+0xc8/0xe8   do_el0_svc+0x20/0x2c   el0_svc+0x28/0x98   el0t_64_sync_handler+0x13c/0x158   el0t_64_sync+0x190/0x194(CVE-2024-50057)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ntfs3: Change to non-blocking allocation in ntfs_d_hash  d_hash is done while under \u0026quot;rcu-walk\u0026quot; and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.(CVE-2024-50065)",
  "id": "OESA-2024-2325",
  "modified": "2026-08-06T11:07:48Z",
  "published": "2024-11-01T11:07:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2325"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52917"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52918"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35949"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35964"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36884"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42301"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43858"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43867"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43871"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44982"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44997"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46675"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46677"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46724"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46749"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46757"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46775"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46782"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46802"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46853"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46871"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47659"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47660"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47661"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47667"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47681"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47683"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47684"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47685"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47689"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47692"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47695"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47698"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47709"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47710"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47720"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47737"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47743"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47757"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49855"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49866"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49867"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49868"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49895"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49900"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49902"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49903"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49911"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49918"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49919"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49927"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49965"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49969"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49974"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49976"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49985"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50007"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50012"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50046"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50049"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50057"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50065"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2023-52917",
    "CVE-2023-52918",
    "CVE-2024-35949",
    "CVE-2024-35964",
    "CVE-2024-36884",
    "CVE-2024-42301",
    "CVE-2024-43858",
    "CVE-2024-43867",
    "CVE-2024-43871",
    "CVE-2024-44982",
    "CVE-2024-44997",
    "CVE-2024-46675",
    "CVE-2024-46677",
    "CVE-2024-46724",
    "CVE-2024-46749",
    "CVE-2024-46757",
    "CVE-2024-46775",
    "CVE-2024-46782",
    "CVE-2024-46802",
    "CVE-2024-46853",
    "CVE-2024-46871",
    "CVE-2024-47659",
    "CVE-2024-47660",
    "CVE-2024-47661",
    "CVE-2024-47667",
    "CVE-2024-47681",
    "CVE-2024-47683",
    "CVE-2024-47684",
    "CVE-2024-47685",
    "CVE-2024-47689",
    "CVE-2024-47692",
    "CVE-2024-47695",
    "CVE-2024-47698",
    "CVE-2024-47709",
    "CVE-2024-47710",
    "CVE-2024-47720",
    "CVE-2024-47737",
    "CVE-2024-47743",
    "CVE-2024-47757",
    "CVE-2024-49855",
    "CVE-2024-49866",
    "CVE-2024-49867",
    "CVE-2024-49868",
    "CVE-2024-49895",
    "CVE-2024-49900",
    "CVE-2024-49902",
    "CVE-2024-49903",
    "CVE-2024-49911",
    "CVE-2024-49918",
    "CVE-2024-49919",
    "CVE-2024-49927",
    "CVE-2024-49965",
    "CVE-2024-49969",
    "CVE-2024-49974",
    "CVE-2024-49976",
    "CVE-2024-49985",
    "CVE-2024-50007",
    "CVE-2024-50012",
    "CVE-2024-50046",
    "CVE-2024-50049",
    "CVE-2024-50057",
    "CVE-2024-50065"
  ]
}