This error can be catched by KASAN:

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "python2-perf-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
          "bpftool-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2406.2.0.0281.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2406.2.0.0281.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2406.2.0.0281.oe2003sp4"
            }
          ],
          "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\nnet: cdc_eem: fix tx fixup skb leak\r\n\r\nwhen usbnet transmit a skb, eem fixup it in eem_tx_fixup(),\nif skb_copy_expand() failed, it return NULL,\nusbnet_start_xmit() will have no chance to free original skb.\r\n\r\nfix it by free orginal skb in eem_tx_fixup() first,\nthen check skb clone status, if failed, return NULL to usbnet.(CVE-2021-47236)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngfs2: Fix use-after-free in gfs2_glock_shrink_scan\r\n\r\nThe GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() to\nremove the glock from the lru list in __gfs2_glock_put().\r\n\r\nOn the shrink scan path, the same flag is cleared under lru_lock but because\nof cond_resched_lock(\u0026amp;lru_lock) in gfs2_dispose_glock_lru(), progress on the\nput side can be made without deleting the glock from the lru list.\r\n\r\nKeep GLF_LRU across the race window opened by cond_resched_lock(\u0026amp;lru_lock) to\nensure correct behavior on both sides - clear GLF_LRU after list_del under\nlru_lock.(CVE-2021-47254)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetrom: Decrease sock refcount when sock timers expire\r\n\r\nCommit 63346650c1a9 (\u0026quot;netrom: switch to sock timer API\u0026quot;) switched to use\nsock timer API. It replaces mod_timer() by sk_reset_timer(), and\ndel_timer() by sk_stop_timer().\r\n\r\nFunction sk_reset_timer() will increase the refcount of sock if it is\ncalled on an inactive timer, hence, in case the timer expires, we need to\ndecrease the refcount ourselves in the handler, otherwise, the sock\nrefcount will be unbalanced and the sock will never be freed.(CVE-2021-47294)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmemory: fsl_ifc: fix leak of IO mapping on probe failure\r\n\r\nOn probe error the driver should unmap the IO memory.  Smatch reports:\r\n\r\n  drivers/memory/fsl_ifc.c:298 fsl_ifc_ctrl_probe() warn: \u0026apos;fsl_ifc_ctrl_dev-\u0026gt;gregs\u0026apos; not released on lines: 298.(CVE-2021-47315)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwatchdog: Fix possible use-after-free in wdt_startup()\r\n\r\nThis module\u0026apos;s remove path calls del_timer(). However, that function\ndoes not wait until the timer handler finishes. This means that the\ntimer handler may still be running after the driver\u0026apos;s remove function\nhas finished, which would result in a use-after-free.\r\n\r\nFix by calling del_timer_sync(), which makes sure the timer handler\nhas finished, and unable to re-schedule itself.(CVE-2021-47324)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: megaraid_sas: Fix resource leak in case of probe failure\r\n\r\nThe driver doesn\u0026apos;t clean up all the allocated resources properly when\nscsi_add_host(), megasas_start_aen() function fails during the PCI device\nprobe.\r\n\r\nClean up all those resources.(CVE-2021-47329)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipack: ipoctal: fix module reference leak\r\n\r\nA reference to the carrier module was taken on every open but was only\nreleased once when the final reference to the tty struct was dropped.\r\n\r\nFix this by taking the module reference and initialising the tty driver\ndata when installing the tty.(CVE-2021-47403)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc2: check return value after calling platform_get_resource()\r\n\r\nIt will cause null-ptr-deref if platform_get_resource() returns NULL,\nwe need check the return value.(CVE-2021-47409)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni40e: Fix freeing of uninitialized misc IRQ vector\r\n\r\nWhen VSI set up failed in i40e_probe() as part of PF switch set up\ndriver was trying to free misc IRQ vectors in\ni40e_clear_interrupt_scheme and produced a kernel Oops:\r\n\r\n   Trying to free already-free IRQ 266\n   WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300\n   Workqueue: events work_for_cpu_fn\n   RIP: 0010:__free_irq+0x9a/0x300\n   Call Trace:\n   ? synchronize_irq+0x3a/0xa0\n   free_irq+0x2e/0x60\n   i40e_clear_interrupt_scheme+0x53/0x190 [i40e]\n   i40e_probe.part.108+0x134b/0x1a40 [i40e]\n   ? kmem_cache_alloc+0x158/0x1c0\n   ? acpi_ut_update_ref_count.part.1+0x8e/0x345\n   ? acpi_ut_update_object_reference+0x15e/0x1e2\n   ? strstr+0x21/0x70\n   ? irq_get_irq_data+0xa/0x20\n   ? mp_check_pin_attr+0x13/0xc0\n   ? irq_get_irq_data+0xa/0x20\n   ? mp_map_pin_to_irq+0xd3/0x2f0\n   ? acpi_register_gsi_ioapic+0x93/0x170\n   ? pci_conf1_read+0xa4/0x100\n   ? pci_bus_read_config_word+0x49/0x70\n   ? do_pci_enable_device+0xcc/0x100\n   local_pci_probe+0x41/0x90\n   work_for_cpu_fn+0x16/0x20\n   process_one_work+0x1a7/0x360\n   worker_thread+0x1cf/0x390\n   ? create_worker+0x1a0/0x1a0\n   kthread+0x112/0x130\n   ? kthread_flush_work_fn+0x10/0x10\n   ret_from_fork+0x1f/0x40\r\n\r\nThe problem is that at that point misc IRQ vectors\nwere not allocated yet and we get a call trace\nthat driver is trying to free already free IRQ vectors.\r\n\r\nAdd a check in i40e_clear_interrupt_scheme for __I40E_MISC_IRQ_REQUESTED\nPF state before calling i40e_free_misc_vector. This state is set only if\nmisc IRQ vectors were properly initialized.(CVE-2021-47424)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: fix data corruption after conversion from inline format\r\n\r\nCommit 6dbf7bb55598 (\u0026quot;fs: Don\u0026apos;t invalidate page buffers in\nblock_write_full_page()\u0026quot;) uncovered a latent bug in ocfs2 conversion\nfrom inline inode format to a normal inode format.\r\n\r\nThe code in ocfs2_convert_inline_data_to_extents() attempts to zero out\nthe whole cluster allocated for file data by grabbing, zeroing, and\ndirtying all pages covering this cluster.  However these pages are\nbeyond i_size, thus writeback code generally ignores these dirty pages\nand no blocks were ever actually zeroed on the disk.\r\n\r\nThis oversight was fixed by commit 693c241a5f6a (\u0026quot;ocfs2: No need to zero\npages past i_size.\u0026quot;) for standard ocfs2 write path, inline conversion\npath was apparently forgotten; the commit log also has a reasoning why\nthe zeroing actually is not needed.\r\n\r\nAfter commit 6dbf7bb55598, things became worse as writeback code stopped\ninvalidating buffers on pages beyond i_size and thus these pages end up\nwith clean PageDirty bit but with buffers attached to these pages being\nstill dirty.  So when a file is converted from inline format, then\nwriteback triggers, and then the file is grown so that these pages\nbecome valid, the invalid dirtiness state is preserved,\nmark_buffer_dirty() does nothing on these pages (buffers are already\ndirty) but page is never written back because it is clean.  So data\nwritten to these pages is lost once pages are reclaimed.\r\n\r\nSimple reproducer for the problem is:\r\n\r\n  xfs_io -f -c \u0026quot;pwrite 0 2000\u0026quot; -c \u0026quot;pwrite 2000 2000\u0026quot; -c \u0026quot;fsync\u0026quot; \\\n    -c \u0026quot;pwrite 4000 2000\u0026quot; ocfs2_file\r\n\r\nAfter unmounting and mounting the fs again, you can observe that end of\n\u0026apos;ocfs2_file\u0026apos; has lost its contents.\r\n\r\nFix the problem by not doing the pointless zeroing during conversion\nfrom inline format similarly as in the standard write path.\r\n\r\n[akpm@linux-foundation.org: fix whitespace, per Joseph](CVE-2021-47460)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncomedi: ni_usb6501: fix NULL-deref in command paths\r\n\r\nThe driver uses endpoint-sized USB transfer buffers but had no sanity\nchecks on the sizes. This can lead to zero-size-pointer dereferences or\noverflowed transfer buffers in ni6501_port_command() and\nni6501_counter_command() if a (malicious) device has smaller max-packet\nsizes than expected (or when doing descriptor fuzz testing).\r\n\r\nAdd the missing sanity checks to probe().(CVE-2021-47476)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nisofs: Fix out of bound access for corrupted isofs image\r\n\r\nWhen isofs image is suitably corrupted isofs_read_inode() can read data\nbeyond the end of buffer. Sanity-check the directory entry length before\nusing it.(CVE-2021-47478)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nstaging: rtl8712: fix use-after-free in rtl8712_dl_fw\r\n\r\nSyzbot reported use-after-free in rtl8712_dl_fw(). The problem was in\nrace condition between r871xu_dev_remove() -\u0026gt;ndo_open() callback.\r\n\r\nIt\u0026apos;s easy to see from crash log, that driver accesses released firmware\nin -\u0026gt;ndo_open() callback. It may happen, since driver was releasing\nfirmware _before_ unregistering netdev. Fix it by moving\nunregister_netdev() before cleaning up resources.\r\n\r\nCall Trace:\n...\n rtl871x_open_fw drivers/staging/rtl8712/hal_init.c:83 [inline]\n rtl8712_dl_fw+0xd95/0xe10 drivers/staging/rtl8712/hal_init.c:170\n rtl8712_hal_init drivers/staging/rtl8712/hal_init.c:330 [inline]\n rtl871x_hal_init+0xae/0x180 drivers/staging/rtl8712/hal_init.c:394\n netdev_open+0xe6/0x6c0 drivers/staging/rtl8712/os_intfs.c:380\n __dev_open+0x2bc/0x4d0 net/core/dev.c:1484\r\n\r\nFreed by task 1306:\n...\n release_firmware+0x1b/0x30 drivers/base/firmware_loader/main.c:1053\n r871xu_dev_remove+0xcc/0x2c0 drivers/staging/rtl8712/usb_intf.c:599\n usb_unbind_interface+0x1d8/0x8d0 drivers/usb/core/driver.c:458(CVE-2021-47479)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niio: accel: kxcjk-1013: Fix possible memory leak in probe and remove\r\n\r\nWhen ACPI type is ACPI_SMO8500, the data-\u0026gt;dready_trig will not be set, the\nmemory allocated by iio_triggered_buffer_setup() will not be freed, and cause\nmemory leak as follows:\r\n\r\nunreferenced object 0xffff888009551400 (size 512):\n  comm \u0026quot;i2c-SMO8500-125\u0026quot;, pid 911, jiffies 4294911787 (age 83.852s)\n  hex dump (first 32 bytes):\n    02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff  ........ .......\n  backtrace:\n    [\u0026lt;0000000041ce75ee\u0026gt;] kmem_cache_alloc_trace+0x16d/0x360\n    [\u0026lt;000000000aeb17b0\u0026gt;] iio_kfifo_allocate+0x41/0x130 [kfifo_buf]\n    [\u0026lt;000000004b40c1f5\u0026gt;] iio_triggered_buffer_setup_ext+0x2c/0x210 [industrialio_triggered_buffer]\n    [\u0026lt;000000004375b15f\u0026gt;] kxcjk1013_probe+0x10c3/0x1d81 [kxcjk_1013]\r\n\r\nFix it by remove data-\u0026gt;dready_trig condition in probe and remove.(CVE-2021-47499)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: pcm: oss: Fix negative period/buffer sizes\r\n\r\nThe period size calculation in OSS layer may receive a negative value\nas an error, but the code there assumes only the positive values and\nhandle them with size_t.  Due to that, a too big value may be passed\nto the lower layers.\r\n\r\nThis patch changes the code to handle with ssize_t and adds the proper\nerror checks appropriately.(CVE-2021-47511)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfc: fix potential NULL pointer deref in nfc_genl_dump_ses_done\r\n\r\nThe done() netlink callback nfc_genl_dump_ses_done() should check if\nreceived argument is non-NULL, because its allocation could fail earlier\nin dumpit() (nfc_genl_dump_ses()).(CVE-2021-47518)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrxrpc: Fix rxrpc_local leak in rxrpc_lookup_peer()\r\n\r\nNeed to call rxrpc_put_local() for peer candidate before kfree() as it\nholds a ref to rxrpc_local.\r\n\r\n[DH: v2: Changed to abstract the peer freeing code out into a function](CVE-2021-47538)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx4_en: Fix an use-after-free bug in mlx4_en_try_alloc_resources()\r\n\r\nIn mlx4_en_try_alloc_resources(), mlx4_en_copy_priv() is called and\ntmp-\u0026gt;tx_cq will be freed on the error path of mlx4_en_copy_priv().\nAfter that mlx4_en_alloc_resources() is called and there is a dereference\nof \u0026amp;tmp-\u0026gt;tx_cq[t][i] in mlx4_en_alloc_resources(), which could lead to\na use after free problem on failure of mlx4_en_copy_priv().\r\n\r\nFix this bug by adding a check of mlx4_en_copy_priv()\r\n\r\nThis bug was found by a static analyzer. The analysis employs\ndifferential checking to identify inconsistent security operations\n(e.g., checks or kfrees) between two code paths and confirms that the\ninconsistent operations are not recovered in the current function or\nthe callers, so they constitute bugs.\r\n\r\nNote that, as a bug found by static analysis, it can be a false\npositive or hard to trigger. Multiple researchers have cross-reviewed\nthe bug.\r\n\r\nBuilds with CONFIG_MLX4_EN=m show no new warnings,\nand our static analyzer no longer warns about this code.(CVE-2021-47541)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings()\r\n\r\nIn qlcnic_83xx_add_rings(), the indirect function of\nahw-\u0026gt;hw_ops-\u0026gt;alloc_mbx_args will be called to allocate memory for\ncmd.req.arg, and there is a dereference of it in qlcnic_83xx_add_rings(),\nwhich could lead to a NULL pointer dereference on failure of the\nindirect function like qlcnic_83xx_alloc_mbx_args().\r\n\r\nFix this bug by adding a check of alloc_mbx_args(), this patch\nimitates the logic of mbx_cmd()\u0026apos;s failure handling.\r\n\r\nThis bug was found by a static analyzer. The analysis employs\ndifferential checking to identify inconsistent security operations\n(e.g., checks or kfrees) between two code paths and confirms that the\ninconsistent operations are not recovered in the current function or\nthe callers, so they constitute bugs.\r\n\r\nNote that, as a bug found by static analysis, it can be a false\npositive or hard to trigger. Multiple researchers have cross-reviewed\nthe bug.\r\n\r\nBuilds with CONFIG_QLCNIC=m show no new warnings, and our\nstatic analyzer no longer warns about this code.(CVE-2021-47542)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2021-47543)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: fix page frag corruption on page fault\r\n\r\nSteffen reported a TCP stream corruption for HTTP requests\nserved by the apache web-server using a cifs mount-point\nand memory mapping the relevant file.\r\n\r\nThe root cause is quite similar to the one addressed by\ncommit 20eb4f29b602 (\u0026quot;net: fix sk_page_frag() recursion from\nmemory reclaim\u0026quot;). Here the nested access to the task page frag\nis caused by a page fault on the (mmapped) user-space memory\nbuffer coming from the cifs file.\r\n\r\nThe page fault handler performs an smb transaction on a different\nsocket, inside the same process context. Since sk-\u0026gt;sk_allaction\nfor such socket does not prevent the usage for the task_frag,\nthe nested allocation modify \u0026quot;under the hood\u0026quot; the page frag\nin use by the outer sendmsg call, corrupting the stream.\r\n\r\nThe overall relevant stack trace looks like the following:\r\n\r\nhttpd 78268 [001] 3461630.850950:      probe:tcp_sendmsg_locked:\n        ffffffff91461d91 tcp_sendmsg_locked+0x1\n        ffffffff91462b57 tcp_sendmsg+0x27\n        ffffffff9139814e sock_sendmsg+0x3e\n        ffffffffc06dfe1d smb_send_kvec+0x28\n        [...]\n        ffffffffc06cfaf8 cifs_readpages+0x213\n        ffffffff90e83c4b read_pages+0x6b\n        ffffffff90e83f31 __do_page_cache_readahead+0x1c1\n        ffffffff90e79e98 filemap_fault+0x788\n        ffffffff90eb0458 __do_fault+0x38\n        ffffffff90eb5280 do_fault+0x1a0\n        ffffffff90eb7c84 __handle_mm_fault+0x4d4\n        ffffffff90eb8093 handle_mm_fault+0xc3\n        ffffffff90c74f6d __do_page_fault+0x1ed\n        ffffffff90c75277 do_page_fault+0x37\n        ffffffff9160111e page_fault+0x1e\n        ffffffff9109e7b5 copyin+0x25\n        ffffffff9109eb40 _copy_from_iter_full+0xe0\n        ffffffff91462370 tcp_sendmsg_locked+0x5e0\n        ffffffff91462370 tcp_sendmsg_locked+0x5e0\n        ffffffff91462b57 tcp_sendmsg+0x27\n        ffffffff9139815c sock_sendmsg+0x4c\n        ffffffff913981f7 sock_write_iter+0x97\n        ffffffff90f2cc56 do_iter_readv_writev+0x156\n        ffffffff90f2dff0 do_iter_write+0x80\n        ffffffff90f2e1c3 vfs_writev+0xa3\n        ffffffff90f2e27c do_writev+0x5c\n        ffffffff90c042bb do_syscall_64+0x5b\n        ffffffff916000ad entry_SYSCALL_64_after_hwframe+0x65\r\n\r\nThe cifs filesystem rightfully sets sk_allocations to GFP_NOFS,\nwe can avoid the nesting using the sk page frag for allocation\nlacking the __GFP_FS flag. Do not define an additional mm-helper\nfor that, as this is strictly tied to the sk page frag usage.\r\n\r\nv1 -\u0026gt; v2:\n - use a stricted sk_page_frag() check instead of reordering the\n   code (Eric)(CVE-2021-47544)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: tulip: de4x5: fix the problem that the array \u0026apos;lp-\u0026gt;phy[8]\u0026apos; may be out of bound\r\n\r\nIn line 5001, if all id in the array \u0026apos;lp-\u0026gt;phy[8]\u0026apos; is not 0, when the\n\u0026apos;for\u0026apos; end, the \u0026apos;k\u0026apos; is 8.\r\n\r\nAt this time, the array \u0026apos;lp-\u0026gt;phy[8]\u0026apos; may be out of bound.(CVE-2021-47547)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/powernv: Add a null pointer check in opal_event_init()\r\n\r\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure.(CVE-2023-52686)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix underflow in second superblock position calculations\r\n\r\nMacro NILFS_SB2_OFFSET_BYTES, which computes the position of the second\nsuperblock, underflows when the argument device size is less than 4096\nbytes.  Therefore, when using this macro, it is necessary to check in\nadvance that the device size is not less than a lower limit, or at least\nthat underflow does not occur.\r\n\r\nThe current nilfs2 implementation lacks this check, causing out-of-bound\nblock access when mounting devices smaller than 4096 bytes:\r\n\r\n I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0\n phys_seg 1 prio class 2\n NILFS (loop0): unable to read secondary superblock (blocksize = 1024)\r\n\r\nIn addition, when trying to resize the filesystem to a size below 4096\nbytes, this underflow occurs in nilfs_resize_fs(), passing a huge number\nof segments to nilfs_sufile_resize(), corrupting parameters such as the\nnumber of segments in superblocks.  This causes excessive loop iterations\nin nilfs_sufile_resize() during a subsequent resize ioctl, causing\nsemaphore ns_segctor_sem to block for a long time and hang the writer\nthread:\r\n\r\n INFO: task segctord:5067 blocked for more than 143 seconds.\n      Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:segctord        state:D stack:23456 pid:5067  ppid:2\n flags:0x00004000\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  context_switch kernel/sched/core.c:5293 [inline]\n  __schedule+0x1409/0x43f0 kernel/sched/core.c:6606\n  schedule+0xc3/0x190 kernel/sched/core.c:6682\n  rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190\n  nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357\n  nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline]\n  nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570\n  kthread+0x270/0x300 kernel/kthread.c:376\n  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308\n  \u0026lt;/TASK\u0026gt;\n ...\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  folio_mark_accessed+0x51c/0xf00 mm/swap.c:515\n  __nilfs_get_page_block fs/nilfs2/page.c:42 [inline]\n  nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61\n  nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121\n  nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176\n  nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251\n  nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline]\n  nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline]\n  nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777\n  nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422\n  nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline]\n  nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301\n  ...\r\n\r\nThis fixes these issues by inserting appropriate minimum device size\nchecks or anti-underflow checks, depending on where the macro is used.(CVE-2023-52705)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Avoid NULL dereference of timing generator\r\n\r\n[Why \u0026amp; How]\nCheck whether assigned timing generator is NULL or not before\naccessing its funcs to prevent NULL dereference.(CVE-2023-52753)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: imon: fix access to invalid resource for the second interface\r\n\r\nimon driver probes two USB interfaces, and at the probe of the second\ninterface, the driver assumes blindly that the first interface got\nbound with the same imon driver.  It\u0026apos;s usually true, but it\u0026apos;s still\npossible that the first interface is bound with another driver via a\nmalformed descriptor.  Then it may lead to a memory corruption, as\nspotted by syzkaller; imon driver accesses the data from drvdata as\nstruct imon_context object although it\u0026apos;s a completely different one\nthat was assigned by another driver.\r\n\r\nThis patch adds a sanity check -- whether the first interface is\nreally bound with the imon driver or not -- for avoiding the problem\nabove at the probe time.(CVE-2023-52754)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2023-52756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/dasd: protect device queue against concurrent access\r\n\r\nIn dasd_profile_start() the amount of requests on the device queue are\ncounted. The access to the device queue is unprotected against\nconcurrent access. With a lot of parallel I/O, especially with alias\ndevices enabled, the device queue can change while dasd_profile_start()\nis accessing the queue. In the worst case this leads to a kernel panic\ndue to incorrect pointer accesses.\r\n\r\nFix this by taking the device lock before accessing the queue and\ncounting the requests. Additionally the check for a valid profile data\npointer can be done earlier to avoid unnecessary locking in a hot path.(CVE-2023-52774)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: Fix RPC client cleaned up the freed pipefs dentries\r\n\r\nRPC client pipefs dentries cleanup is in separated rpc_remove_pipedir()\nworkqueue,which takes care about pipefs superblock locking.\nIn some special scenarios, when kernel frees the pipefs sb of the\ncurrent client and immediately alloctes a new pipefs sb,\nrpc_remove_pipedir function would misjudge the existence of pipefs\nsb which is not the one it used to hold. As a result,\nthe rpc_remove_pipedir would clean the released freed pipefs dentries.\r\n\r\nTo fix this issue, rpc_remove_pipedir should check whether the\ncurrent pipefs sb is consistent with the original pipefs sb.\r\n\r\nThis error can be catched by KASAN:\n=========================================================\n[  250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200\n[  250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503\n[  250.500549] Workqueue: events rpc_free_client_work\n[  250.501001] Call Trace:\n[  250.502880]  kasan_report+0xb6/0xf0\n[  250.503209]  ? dget_parent+0x195/0x200\n[  250.503561]  dget_parent+0x195/0x200\n[  250.503897]  ? __pfx_rpc_clntdir_depopulate+0x10/0x10\n[  250.504384]  rpc_rmdir_depopulate+0x1b/0x90\n[  250.504781]  rpc_remove_client_dir+0xf5/0x150\n[  250.505195]  rpc_free_client_work+0xe4/0x230\n[  250.505598]  process_one_work+0x8ee/0x13b0\n...\n[   22.039056] Allocated by task 244:\n[   22.039390]  kasan_save_stack+0x22/0x50\n[   22.039758]  kasan_set_track+0x25/0x30\n[   22.040109]  __kasan_slab_alloc+0x59/0x70\n[   22.040487]  kmem_cache_alloc_lru+0xf0/0x240\n[   22.040889]  __d_alloc+0x31/0x8e0\n[   22.041207]  d_alloc+0x44/0x1f0\n[   22.041514]  __rpc_lookup_create_exclusive+0x11c/0x140\n[   22.041987]  rpc_mkdir_populate.constprop.0+0x5f/0x110\n[   22.042459]  rpc_create_client_dir+0x34/0x150\n[   22.042874]  rpc_setup_pipedir_sb+0x102/0x1c0\n[   22.043284]  rpc_client_register+0x136/0x4e0\n[   22.043689]  rpc_new_client+0x911/0x1020\n[   22.044057]  rpc_create_xprt+0xcb/0x370\n[   22.044417]  rpc_create+0x36b/0x6c0\n...\n[   22.049524] Freed by task 0:\n[   22.049803]  kasan_save_stack+0x22/0x50\n[   22.050165]  kasan_set_track+0x25/0x30\n[   22.050520]  kasan_save_free_info+0x2b/0x50\n[   22.050921]  __kasan_slab_free+0x10e/0x1a0\n[   22.051306]  kmem_cache_free+0xa5/0x390\n[   22.051667]  rcu_core+0x62c/0x1930\n[   22.051995]  __do_softirq+0x165/0x52a\n[   22.052347]\n[   22.052503] Last potentially related work creation:\n[   22.052952]  kasan_save_stack+0x22/0x50\n[   22.053313]  __kasan_record_aux_stack+0x8e/0xa0\n[   22.053739]  __call_rcu_common.constprop.0+0x6b/0x8b0\n[   22.054209]  dentry_free+0xb2/0x140\n[   22.054540]  __dentry_kill+0x3be/0x540\n[   22.054900]  shrink_dentry_list+0x199/0x510\n[   22.055293]  shrink_dcache_parent+0x190/0x240\n[   22.055703]  do_one_tree+0x11/0x40\n[   22.056028]  shrink_dcache_for_umount+0x61/0x140\n[   22.056461]  generic_shutdown_super+0x70/0x590\n[   22.056879]  kill_anon_super+0x3a/0x60\n[   22.057234]  rpc_kill_sb+0x121/0x200(CVE-2023-52803)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nplatform/x86: wmi: Fix opening of char device\r\n\r\nSince commit fa1f68db6ca7 (\u0026quot;drivers: misc: pass miscdevice pointer via\nfile private data\u0026quot;), the miscdevice stores a pointer to itself inside\nfilp-\u0026gt;private_data, which means that private_data will not be NULL when\nwmi_char_open() is called. This might cause memory corruption should\nwmi_char_open() be unable to find its driver, something which can\nhappen when the associated WMI device is deleted in wmi_free_devices().\r\n\r\nFix the problem by using the miscdevice pointer to retrieve the WMI\ndevice data associated with a char device using container_of(). This\nalso avoids wmi_char_open() picking a wrong WMI device bound to a\ndriver with the same name as the original driver.(CVE-2023-52864)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data\r\n\r\nAdd the check for the return value of mtk_alloc_clk_data() in order to\navoid NULL pointer dereference.(CVE-2023-52865)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: qcom: llcc: Handle a second device without data corruption\r\n\r\nUsually there is only one llcc device. But if there were a second, even\na failed probe call would modify the global drv_data pointer. So check\nif drv_data is valid before overwriting it.(CVE-2023-52871)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nefi/capsule-loader: fix incorrect allocation size\r\n\r\ngcc-14 notices that the allocation with sizeof(void) on 32-bit architectures\nis not enough for a 64-bit phys_addr_t:\r\n\r\ndrivers/firmware/efi/capsule-loader.c: In function \u0026apos;efi_capsule_open\u0026apos;:\ndrivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size \u0026apos;4\u0026apos; for type \u0026apos;phys_addr_t\u0026apos; {aka \u0026apos;long long unsigned int\u0026apos;} with size \u0026apos;8\u0026apos; [-Werror=alloc-size]\n  295 |         cap_info-\u0026gt;phys = kzalloc(sizeof(void *), GFP_KERNEL);\n      |                        ^\r\n\r\nUse the correct type instead here.(CVE-2024-27413)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI/PM: Drain runtime-idle callbacks before driver removal\r\n\r\nA race condition between the .runtime_idle() callback and the .remove()\ncallback in the rtsx_pcr PCI driver leads to a kernel crash due to an\nunhandled page fault [1].\r\n\r\nThe problem is that rtsx_pci_runtime_idle() is not expected to be running\nafter pm_runtime_get_sync() has been called, but the latter doesn\u0026apos;t really\nguarantee that.  It only guarantees that the suspend and resume callbacks\nwill not be running when it returns.\r\n\r\nHowever, if a .runtime_idle() callback is already running when\npm_runtime_get_sync() is called, the latter will notice that the runtime PM\nstatus of the device is RPM_ACTIVE and it will return right away without\nwaiting for the former to complete.  In fact, it cannot wait for\n.runtime_idle() to complete because it may be called from that callback (it\narguably does not make much sense to do that, but it is not strictly\nprohibited).\r\n\r\nThus in general, whoever is providing a .runtime_idle() callback needs\nto protect it from running in parallel with whatever code runs after\npm_runtime_get_sync().  [Note that .runtime_idle() will not start after\npm_runtime_get_sync() has returned, but it may continue running then if it\nhas started earlier.]\r\n\r\nOne way to address that race condition is to call pm_runtime_barrier()\nafter pm_runtime_get_sync() (not before it, because a nonzero value of the\nruntime PM usage counter is necessary to prevent runtime PM callbacks from\nbeing invoked) to wait for the .runtime_idle() callback to complete should\nit be running at that point.  A suitable place for doing that is in\npci_device_remove() which calls pm_runtime_get_sync() before removing the\ndriver, so it may as well call pm_runtime_barrier() subsequently, which\nwill prevent the race in question from occurring, not just in the rtsx_pcr\ndriver, but in any PCI drivers providing .runtime_idle() callbacks.(CVE-2024-35809)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach\r\n\r\nThis is the candidate patch of CVE-2023-47233 :\nhttps://nvd.nist.gov/vuln/detail/CVE-2023-47233\r\n\r\nIn brcm80211 driver,it starts with the following invoking chain\nto start init a timeout worker:\r\n\r\n-\u0026gt;brcmf_usb_probe\n  -\u0026gt;brcmf_usb_probe_cb\n    -\u0026gt;brcmf_attach\n      -\u0026gt;brcmf_bus_started\n        -\u0026gt;brcmf_cfg80211_attach\n          -\u0026gt;wl_init_priv\n            -\u0026gt;brcmf_init_escan\n              -\u0026gt;INIT_WORK(\u0026amp;cfg-\u0026gt;escan_timeout_work,\n\t\t  brcmf_cfg80211_escan_timeout_worker);\r\n\r\nIf we disconnect the USB by hotplug, it will call\nbrcmf_usb_disconnect to make cleanup. The invoking chain is :\r\n\r\nbrcmf_usb_disconnect\n  -\u0026gt;brcmf_usb_disconnect_cb\n    -\u0026gt;brcmf_detach\n      -\u0026gt;brcmf_cfg80211_detach\n        -\u0026gt;kfree(cfg);\r\n\r\nWhile the timeout woker may still be running. This will cause\na use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.\r\n\r\nFix it by deleting the timer and canceling the worker in\nbrcmf_cfg80211_detach.\r\n\r\n[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free](CVE-2024-35811)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nerspan: make sure erspan_base_hdr is present in skb-\u0026gt;head\r\n\r\nsyzbot reported a problem in ip6erspan_rcv() [1]\r\n\r\nIssue is that ip6erspan_rcv() (and erspan_rcv()) no longer make\nsure erspan_base_hdr is present in skb linear part (skb-\u0026gt;head)\nbefore getting @ver field from it.\r\n\r\nAdd the missing pskb_may_pull() calls.\r\n\r\nv2: Reload iph pointer in erspan_rcv() after pskb_may_pull()\n    because skb-\u0026gt;head might have changed.\r\n\r\n[1]\r\n\r\n BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]\n BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline]\n BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]\n BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610\n  pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]\n  pskb_may_pull include/linux/skbuff.h:2756 [inline]\n  ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]\n  gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610\n  ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438\n  ip6_input_finish net/ipv6/ip6_input.c:483 [inline]\n  NF_HOOK include/linux/netfilter.h:314 [inline]\n  ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492\n  ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586\n  dst_input include/net/dst.h:460 [inline]\n  ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79\n  NF_HOOK include/linux/netfilter.h:314 [inline]\n  ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310\n  __netif_receive_skb_one_core net/core/dev.c:5538 [inline]\n  __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652\n  netif_receive_skb_internal net/core/dev.c:5738 [inline]\n  netif_receive_skb+0x58/0x660 net/core/dev.c:5798\n  tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549\n  tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002\n  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n  call_write_iter include/linux/fs.h:2108 [inline]\n  new_sync_write fs/read_write.c:497 [inline]\n  vfs_write+0xb63/0x1520 fs/read_write.c:590\n  ksys_write+0x20f/0x4c0 fs/read_write.c:643\n  __do_sys_write fs/read_write.c:655 [inline]\n  __se_sys_write fs/read_write.c:652 [inline]\n  __x64_sys_write+0x93/0xe0 fs/read_write.c:652\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:3804 [inline]\n  slab_alloc_node mm/slub.c:3845 [inline]\n  kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888\n  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577\n  __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668\n  alloc_skb include/linux/skbuff.h:1318 [inline]\n  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504\n  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795\n  tun_alloc_skb drivers/net/tun.c:1525 [inline]\n  tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846\n  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n  call_write_iter include/linux/fs.h:2108 [inline]\n  new_sync_write fs/read_write.c:497 [inline]\n  vfs_write+0xb63/0x1520 fs/read_write.c:590\n  ksys_write+0x20f/0x4c0 fs/read_write.c:643\n  __do_sys_write fs/read_write.c:655 [inline]\n  __se_sys_write fs/read_write.c:652 [inline]\n  __x64_sys_write+0x93/0xe0 fs/read_write.c:652\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nCPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0(CVE-2024-35888)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: validate user input for expected length\r\n\r\nI got multiple syzbot reports showing old bugs exposed\nby BPF after commit 20f2505fb436 (\u0026quot;bpf: Try to avoid kzalloc\nin cgroup/{s,g}etsockopt\u0026quot;)\r\n\r\nsetsockopt() @optlen argument should be taken into account\nbefore copying data.\r\n\r\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]\n BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]\n BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627\nRead of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238\r\n\r\nCPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n  print_address_description mm/kasan/report.c:377 [inline]\n  print_report+0x169/0x550 mm/kasan/report.c:488\n  kasan_report+0x143/0x180 mm/kasan/report.c:601\n  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n  __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105\n  copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n  copy_from_sockptr include/linux/sockptr.h:55 [inline]\n  do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]\n  do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627\n  nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101\n  do_sock_setsockopt+0x3af/0x720 net/socket.c:2311\n  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n  __do_sys_setsockopt net/socket.c:2343 [inline]\n  __se_sys_setsockopt net/socket.c:2340 [inline]\n  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x72/0x7a\nRIP: 0033:0x7fd22067dde9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036\nRAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9\nRDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 7238:\n  kasan_save_stack mm/kasan/common.c:47 [inline]\n  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n  poison_kmalloc_redzone mm/kasan/common.c:370 [inline]\n  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387\n  kasan_kmalloc include/linux/kasan.h:211 [inline]\n  __do_kmalloc_node mm/slub.c:4069 [inline]\n  __kmalloc_noprof+0x200/0x410 mm/slub.c:4082\n  kmalloc_noprof include/linux/slab.h:664 [inline]\n  __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869\n  do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293\n  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n  __do_sys_setsockopt net/socket.c:2343 [inline]\n  __se_sys_setsockopt net/socket.c:2340 [inline]\n  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x72/0x7a\r\n\r\nThe buggy address belongs to the object at ffff88802cd73da0\n which belongs to the cache kmalloc-8 of size 8\nThe buggy address is located 0 bytes inside of\n allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)\r\n\r\nThe buggy address belongs to the physical page:\npage: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73\nflags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)\npage_type: 0xffffefff(slab)\nraw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122\nraw: ffff88802cd73020 000000008080007f 00000001ffffefff 00\n---truncated---(CVE-2024-35896)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: smbus: fix NULL function pointer dereference\r\n\r\nBaruch reported an OOPS when using the designware controller as target\nonly. Target-only modes break the assumption of one transfer function\nalways being available. Fix this by always checking the pointer in\n__i2c_transfer.\r\n\r\n[wsa: dropped the simplification in core-smbus to avoid theoretical regressions](CVE-2024-35984)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation\r\n\r\nEach attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a\nstruct ifla_vf_vlan_info so the size of such attribute needs to be at least\nof sizeof(struct ifla_vf_vlan_info) which is 14 bytes.\nThe current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes)\nwhich is less than sizeof(struct ifla_vf_vlan_info) so this validation\nis not enough and a too small attribute might be cast to a\nstruct ifla_vf_vlan_info, this might result in an out of bands\nread access when accessing the saved (casted) entry in ivvl.(CVE-2024-36017)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: sdhci-msm: pervent access to suspended controller\r\n\r\nGeneric sdhci code registers LED device and uses host-\u0026gt;runtime_suspended\nflag to protect access to it. The sdhci-msm driver doesn\u0026apos;t set this flag,\nwhich causes a crash when LED is accessed while controller is runtime\nsuspended. Fix this by setting the flag correctly.(CVE-2024-36029)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fix out-of-bounds access in ops_init\r\n\r\nnet_alloc_generic is called by net_alloc, which is called without any\nlocking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It\nis read twice, first to allocate an array, then to set s.len, which is\nlater used to limit the bounds of the array access.\r\n\r\nIt is possible that the array is allocated and another thread is\nregistering a new pernet ops, increments max_gen_ptrs, which is then used\nto set s.len with a larger than allocated length for the variable array.\r\n\r\nFix it by reading max_gen_ptrs only once in net_alloc_generic. If\nmax_gen_ptrs is later incremented, it will be caught in net_assign_generic.(CVE-2024-36883)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()\r\n\r\nsyzbot is able to trigger the following crash [1],\ncaused by unsafe ip6_dst_idev() use.\r\n\r\nIndeed ip6_dst_idev() can return NULL, and must always be checked.\r\n\r\n[1]\r\n\r\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\n RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline]\n RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267\nCode: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 \u0026lt;42\u0026gt; 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c\nRSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700\nRDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760\nRBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd\nR10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000\nR13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00\nFS:  00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317\n  fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108\n  ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline]\n  ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649\n  ip6_route_output include/net/ip6_route.h:93 [inline]\n  ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120\n  ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250\n  sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326\n  sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455\n  sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662\n  sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099\n  __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197\n  sctp_connect net/sctp/socket.c:4819 [inline]\n  sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834\n  __sys_connect_file net/socket.c:2048 [inline]\n  __sys_connect+0x2df/0x310 net/socket.c:2065\n  __do_sys_connect net/socket.c:2075 [inline]\n  __se_sys_connect net/socket.c:2072 [inline]\n  __x64_sys_connect+0x7a/0x90 net/socket.c:2072\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-36902)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: Fix potential uninit-value access in __ip6_make_skb()\r\n\r\nAs it was done in commit fc1092f51567 (\u0026quot;ipv4: Fix uninit-value access in\n__ip_make_skb()\u0026quot;) for IPv4, check FLOWI_FLAG_KNOWN_NH on fl6-\u0026gt;flowi6_flags\ninstead of testing HDRINCL on the socket to avoid a race condition which\ncauses uninit-value access.(CVE-2024-36903)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nblock: fix overflow in blk_ioctl_discard()\r\n\r\nThere is no check for overflow of \u0026apos;start + len\u0026apos; in blk_ioctl_discard().\nHung task occurs if submit an discard ioctl with the following param:\n  start = 0x80000000000ff000, len = 0x8000000000fff000;\nAdd the overflow validation now.(CVE-2024-36917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()\r\n\r\nlpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the\nhbalock.  Thus, lpfc_worker_wake_up() should not be called while holding the\nhbalock to avoid potential deadlock.(CVE-2024-36924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: fix a possible memleak in tipc_buf_append\r\n\r\n__skb_linearize() doesn\u0026apos;t free the skb when it fails, so move\n\u0026apos;*buf = NULL\u0026apos; after __skb_linearize(), so that the skb can be\nfreed on the err path.(CVE-2024-36954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/9p: only translate RWX permissions for plain 9P2000\r\n\r\nGarbage in plain 9P2000\u0026apos;s perm bits is allowed through, which causes it\nto be able to set (among others) the suid bit. This was presumably not\nthe intent since the unix extended bits are handled explicitly and\nconditionally on .u.(CVE-2024-36964)",
  "id": "OESA-2024-1705",
  "modified": "2026-08-06T11:07:10Z",
  "published": "2024-06-14T11:07:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1705"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47236"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47254"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47294"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47315"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47324"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47329"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47403"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47409"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47424"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47460"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47476"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47478"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47479"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47499"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47511"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47518"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47538"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47541"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47542"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47543"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47544"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47547"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52686"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52705"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52753"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52754"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52756"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52774"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52803"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52864"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52865"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52871"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27413"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35809"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35811"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35888"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35896"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35984"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36017"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36029"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36883"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36902"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36903"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36917"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36924"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36954"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36964"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2021-47236",
    "CVE-2021-47254",
    "CVE-2021-47294",
    "CVE-2021-47315",
    "CVE-2021-47324",
    "CVE-2021-47329",
    "CVE-2021-47403",
    "CVE-2021-47409",
    "CVE-2021-47424",
    "CVE-2021-47460",
    "CVE-2021-47476",
    "CVE-2021-47478",
    "CVE-2021-47479",
    "CVE-2021-47499",
    "CVE-2021-47511",
    "CVE-2021-47518",
    "CVE-2021-47538",
    "CVE-2021-47541",
    "CVE-2021-47542",
    "CVE-2021-47543",
    "CVE-2021-47544",
    "CVE-2021-47547",
    "CVE-2023-52686",
    "CVE-2023-52705",
    "CVE-2023-52753",
    "CVE-2023-52754",
    "CVE-2023-52756",
    "CVE-2023-52774",
    "CVE-2023-52803",
    "CVE-2023-52864",
    "CVE-2023-52865",
    "CVE-2023-52871",
    "CVE-2024-27413",
    "CVE-2024-35809",
    "CVE-2024-35811",
    "CVE-2024-35888",
    "CVE-2024-35896",
    "CVE-2024-35984",
    "CVE-2024-36017",
    "CVE-2024-36029",
    "CVE-2024-36883",
    "CVE-2024-36902",
    "CVE-2024-36903",
    "CVE-2024-36917",
    "CVE-2024-36924",
    "CVE-2024-36954",
    "CVE-2024-36964"
  ]
}