{"schema_version":"1.7.2","id":"OESA-2024-2325","modified":"2024-11-01T11:09:31Z","published":"2024-11-01T11:09:31Z","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"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  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)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-48.0.0.53.oe2403"}]}],"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"]}}],"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"}],"database_specific":{"severity":"Critical"}}