{"schema_version":"1.7.2","id":"OESA-2024-2109","modified":"2024-09-06T11:09:04Z","published":"2024-09-06T11:09:04Z","upstream":["CVE-2022-48877","CVE-2022-48891","CVE-2022-48908","CVE-2022-48937","CVE-2023-52899","CVE-2024-40901","CVE-2024-42131","CVE-2024-42286","CVE-2024-42292","CVE-2024-42311","CVE-2024-42312","CVE-2024-43883","CVE-2024-43890","CVE-2024-43900","CVE-2024-44944"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: let\u0026apos;s avoid panic if extent_tree is not created\r\n\r\nThis patch avoids the below panic.\r\n\r\npc : __lookup_extent_tree+0xd8/0x760\nlr : f2fs_do_write_data_page+0x104/0x87c\nsp : ffffffc010cbb3c0\nx29: ffffffc010cbb3e0 x28: 0000000000000000\nx27: ffffff8803e7f020 x26: ffffff8803e7ed40\nx25: ffffff8803e7f020 x24: ffffffc010cbb460\nx23: ffffffc010cbb480 x22: 0000000000000000\nx21: 0000000000000000 x20: ffffffff22e90900\nx19: 0000000000000000 x18: ffffffc010c5d080\nx17: 0000000000000000 x16: 0000000000000020\nx15: ffffffdb1acdbb88 x14: ffffff888759e2b0\nx13: 0000000000000000 x12: ffffff802da49000\nx11: 000000000a001200 x10: ffffff8803e7ed40\nx9 : ffffff8023195800 x8 : ffffff802da49078\nx7 : 0000000000000001 x6 : 0000000000000000\nx5 : 0000000000000006 x4 : ffffffc010cbba28\nx3 : 0000000000000000 x2 : ffffffc010cbb480\nx1 : 0000000000000000 x0 : ffffff8803e7ed40\nCall trace:\n __lookup_extent_tree+0xd8/0x760\n f2fs_do_write_data_page+0x104/0x87c\n f2fs_write_single_data_page+0x420/0xb60\n f2fs_write_cache_pages+0x418/0xb1c\n __f2fs_write_data_pages+0x428/0x58c\n f2fs_write_data_pages+0x30/0x40\n do_writepages+0x88/0x190\n __writeback_single_inode+0x48/0x448\n writeback_sb_inodes+0x468/0x9e8\n __writeback_inodes_wb+0xb8/0x2a4\n wb_writeback+0x33c/0x740\n wb_do_writeback+0x2b4/0x400\n wb_workfn+0xe4/0x34c\n process_one_work+0x24c/0x5bc\n worker_thread+0x3e8/0xa50\n kthread+0x150/0x1b4(CVE-2022-48877)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nregulator: da9211: Use irq handler when ready\r\n\r\nIf the system does not come from reset (like when it is kexec()), the\nregulator might have an IRQ waiting for us.\r\n\r\nIf we enable the IRQ handler before its structures are ready, we crash.\r\n\r\nThis patch fixes:\r\n\r\n[    1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078\n[    1.316096] Call trace:\n[    1.316101]  blocking_notifier_call_chain+0x20/0xa8\n[    1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests\n[    1.327823]  regulator_notifier_call_chain+0x1c/0x2c\n[    1.327825]  da9211_irq_handler+0x68/0xf8\n[    1.327829]  irq_thread+0x11c/0x234\n[    1.327833]  kthread+0x13c/0x154(CVE-2022-48891)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: arcnet: com20020: Fix null-ptr-deref in com20020pci_probe()\r\n\r\nDuring driver initialization, the pointer of card info, i.e. the\nvariable \u0026apos;ci\u0026apos; is required. However, the definition of\n\u0026apos;com20020pci_id_table\u0026apos; reveals that this field is empty for some\ndevices, which will cause null pointer dereference when initializing\nthese devices.\r\n\r\nThe following log reveals it:\r\n\r\n[    3.973806] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n[    3.973819] RIP: 0010:com20020pci_probe+0x18d/0x13e0 [com20020_pci]\n[    3.975181] Call Trace:\n[    3.976208]  local_pci_probe+0x13f/0x210\n[    3.977248]  pci_device_probe+0x34c/0x6d0\n[    3.977255]  ? pci_uevent+0x470/0x470\n[    3.978265]  really_probe+0x24c/0x8d0\n[    3.978273]  __driver_probe_device+0x1b3/0x280\n[    3.979288]  driver_probe_device+0x50/0x370\r\n\r\nFix this by checking whether the \u0026apos;ci\u0026apos; is a null pointer first.(CVE-2022-48908)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring: add a schedule point in io_add_buffers()\r\n\r\nLooping ~65535 times doing kmalloc() calls can trigger soft lockups,\nespecially with DEBUG features (like KASAN).\r\n\r\n[  253.536212] watchdog: BUG: soft lockup - CPU#64 stuck for 26s! [b219417889:12575]\n[  253.544433] Modules linked in: vfat fat i2c_mux_pca954x i2c_mux spidev cdc_acm xhci_pci xhci_hcd sha3_generic gq(O)\n[  253.544451] CPU: 64 PID: 12575 Comm: b219417889 Tainted: G S         O      5.17.0-smp-DEV #801\n[  253.544457] RIP: 0010:kernel_text_address (./include/asm-generic/sections.h:192 ./include/linux/kallsyms.h:29 kernel/extable.c:67 kernel/extable.c:98)\n[  253.544464] Code: 0f 93 c0 48 c7 c1 e0 63 d7 a4 48 39 cb 0f 92 c1 20 c1 0f b6 c1 5b 5d c3 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 53 48 89 fb \u0026lt;48\u0026gt; c7 c0 00 00 80 a0 41 be 01 00 00 00 48 39 c7 72 0c 48 c7 c0 40\n[  253.544468] RSP: 0018:ffff8882d8baf4c0 EFLAGS: 00000246\n[  253.544471] RAX: 1ffff1105b175e00 RBX: ffffffffa13ef09a RCX: 00000000a13ef001\n[  253.544474] RDX: ffffffffa13ef09a RSI: ffff8882d8baf558 RDI: ffffffffa13ef09a\n[  253.544476] RBP: ffff8882d8baf4d8 R08: ffff8882d8baf5e0 R09: 0000000000000004\n[  253.544479] R10: ffff8882d8baf5e8 R11: ffffffffa0d59a50 R12: ffff8882eab20380\n[  253.544481] R13: ffffffffa0d59a50 R14: dffffc0000000000 R15: 1ffff1105b175eb0\n[  253.544483] FS:  00000000016d3380(0000) GS:ffff88af48c00000(0000) knlGS:0000000000000000\n[  253.544486] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  253.544488] CR2: 00000000004af0f0 CR3: 00000002eabfa004 CR4: 00000000003706e0\n[  253.544491] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  253.544492] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  253.544494] Call Trace:\n[  253.544496]  \u0026lt;TASK\u0026gt;\n[  253.544498] ? io_queue_sqe (fs/io_uring.c:7143)\n[  253.544505] __kernel_text_address (kernel/extable.c:78)\n[  253.544508] unwind_get_return_address (arch/x86/kernel/unwind_frame.c:19)\n[  253.544514] arch_stack_walk (arch/x86/kernel/stacktrace.c:27)\n[  253.544517] ? io_queue_sqe (fs/io_uring.c:7143)\n[  253.544521] stack_trace_save (kernel/stacktrace.c:123)\n[  253.544527] ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515)\n[  253.544531] ? ____kasan_kmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515)\n[  253.544533] ? __kasan_kmalloc (mm/kasan/common.c:524)\n[  253.544535] ? kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567)\n[  253.544541] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)\n[  253.544544] ? __io_queue_sqe (fs/io_uring.c:?)\n[  253.544551] __kasan_kmalloc (mm/kasan/common.c:524)\n[  253.544553] kmem_cache_alloc_trace (./include/linux/kasan.h:270 mm/slab.c:3567)\n[  253.544556] ? io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)\n[  253.544560] io_issue_sqe (fs/io_uring.c:4556 fs/io_uring.c:4589 fs/io_uring.c:6828)\n[  253.544564] ? __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)\n[  253.544567] ? __kasan_slab_alloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)\n[  253.544569] ? kmem_cache_alloc_bulk (mm/slab.h:732 mm/slab.c:3546)\n[  253.544573] ? __io_alloc_req_refill (fs/io_uring.c:2078)\n[  253.544578] ? io_submit_sqes (fs/io_uring.c:7441)\n[  253.544581] ? __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uring.c:10096)\n[  253.544584] ? __x64_sys_io_uring_enter (fs/io_uring.c:10096)\n[  253.544587] ? do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)\n[  253.544590] ? entry_SYSCALL_64_after_hwframe (??:?)\n[  253.544596] __io_queue_sqe (fs/io_uring.c:?)\n[  253.544600] io_queue_sqe (fs/io_uring.c:7143)\n[  253.544603] io_submit_sqe (fs/io_uring.c:?)\n[  253.544608] io_submit_sqes (fs/io_uring.c:?)\n[  253.544612] __se_sys_io_uring_enter (fs/io_uring.c:10154 fs/io_uri\n---truncated---(CVE-2022-48937)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nAdd exception protection processing for vd in axi_chan_handle_err function\r\n\r\nSince there is no protection for vd, a kernel panic will be\ntriggered here in exceptional cases.\r\n\r\nYou can refer to the processing of axi_chan_block_xfer_complete function\r\n\r\nThe triggered kernel panic is as follows:\r\n\r\n[   67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060\n[   67.848447] Mem abort info:\n[   67.848449]   ESR = 0x96000004\n[   67.848451]   EC = 0x25: DABT (current EL), IL = 32 bits\n[   67.848454]   SET = 0, FnV = 0\n[   67.848456]   EA = 0, S1PTW = 0\n[   67.848458] Data abort info:\n[   67.848460]   ISV = 0, ISS = 0x00000004\n[   67.848462]   CM = 0, WnR = 0\n[   67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000\n[   67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000\n[   67.848472] Internal error: Oops: 96000004 [#1] SMP\n[   67.848475] Modules linked in: dmatest\n[   67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11\n[   67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--)\n[   67.848487] pc : axi_chan_handle_err+0xc4/0x230\n[   67.848491] lr : axi_chan_handle_err+0x30/0x230\n[   67.848493] sp : ffff0803fe55ae50\n[   67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200\n[   67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080\n[   67.848504] x25: ffff800010d33880 x24: ffff80001139d850\n[   67.848508] x23: ffff0800c097c168 x22: 0000000000000000\n[   67.848512] x21: 0000000000000080 x20: 0000000000002000\n[   67.848517] x19: ffff0800c097c080 x18: 0000000000000000\n[   67.848521] x17: 0000000000000000 x16: 0000000000000000\n[   67.848525] x15: 0000000000000000 x14: 0000000000000000\n[   67.848529] x13: 0000000000000000 x12: 0000000000000040\n[   67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a\n[   67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270\n[   67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0\n[   67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480\n[   67.848550] x3 : dead000000000100 x2 : dead000000000122\n[   67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168\n[   67.848559] Call trace:\n[   67.848562]  axi_chan_handle_err+0xc4/0x230\n[   67.848566]  dw_axi_dma_interrupt+0xf4/0x590\n[   67.848569]  __handle_irq_event_percpu+0x60/0x220\n[   67.848573]  handle_irq_event+0x64/0x120\n[   67.848576]  handle_fasteoi_irq+0xc4/0x220\n[   67.848580]  __handle_domain_irq+0x80/0xe0\n[   67.848583]  gic_handle_irq+0xc0/0x138\n[   67.848585]  el1_irq+0xc8/0x180\n[   67.848588]  arch_cpu_idle+0x14/0x2c\n[   67.848591]  default_idle_call+0x40/0x16c\n[   67.848594]  do_idle+0x1f0/0x250\n[   67.848597]  cpu_startup_entry+0x2c/0x60\n[   67.848600]  rest_init+0xc0/0xcc\n[   67.848603]  arch_call_rest_init+0x14/0x1c\n[   67.848606]  start_kernel+0x4cc/0x500\n[   67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1)\n[   67.848613] ---[ end trace 585a97036f88203a ]---(CVE-2023-52899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory\r\n\r\nThere is a potential out-of-bounds access when using test_bit() on a single\nword. The test_bit() and set_bit() functions operate on long values, and\nwhen testing or setting a single word, they can exceed the word\nboundary. KASAN detects this issue and produces a dump:\r\n\r\n\t BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas\r\n\r\n\t Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965\r\n\r\nFor full log, please look at [1].\r\n\r\nMake the allocation at least the size of sizeof(unsigned long) so that\nset_bit() and test_bit() have sufficient room for read/write operations\nwithout overwriting unallocated memory.\r\n\r\n[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/(CVE-2024-40901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: avoid overflows in dirty throttling logic\r\n\r\nThe dirty throttling logic is interspersed with assumptions that dirty\nlimits in PAGE_SIZE units fit into 32-bit (so that various multiplications\nfit into 64-bits).  If limits end up being larger, we will hit overflows,\npossible divisions by 0 etc.  Fix these problems by never allowing so\nlarge dirty limits as they have dubious practical value anyway.  For\ndirty_bytes / dirty_background_bytes interfaces we can just refuse to set\nso large limits.  For dirty_ratio / dirty_background_ratio it isn\u0026apos;t so\nsimple as the dirty limit is computed from the amount of available memory\nwhich can change due to memory hotplug etc.  So when converting dirty\nlimits from ratios to numbers of pages, we just don\u0026apos;t allow the result to\nexceed UINT_MAX.\r\n\r\nThis is root-only triggerable problem which occurs when the operator\nsets dirty limits to \u0026gt;16 TB.(CVE-2024-42131)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: validate nvme_local_port correctly\r\n\r\nThe driver load failed with error message,\r\n\r\nqla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef\r\n\r\nand with a kernel crash,\r\n\r\n\tBUG: unable to handle kernel NULL pointer dereference at 0000000000000070\n\tWorkqueue: events_unbound qla_register_fcport_fn [qla2xxx]\n\tRIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]\n\tRSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282\n\tRAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000\n\tRDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000\n\tRBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030\n\tR10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4\n\tR13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8\n\tFS:  0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000\n\tCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n\tCR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0\n\tCall Trace:\n\tqla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]\n\t? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]\n\tqla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]\n\tqla_register_fcport_fn+0x54/0xc0 [qla2xxx]\r\n\r\nExit the qla_nvme_register_remote() function when qla_nvme_register_hba()\nfails and correctly validate nvme_local_port.(CVE-2024-42286)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkobject_uevent: Fix OOB access within zap_modalias_env()\r\n\r\nzap_modalias_env() wrongly calculates size of memory block to move, so\nwill cause OOB memory access issue if variable MODALIAS is not the last\none within its @env parameter, fixed by correcting size to memmove.(CVE-2024-42292)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode()\r\n\r\nSyzbot reports uninitialized value access issue as below:\r\n\r\nloop0: detected capacity change from 0 to 64\n=====================================================\nBUG: KMSAN: uninit-value in hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30\n hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30\n d_revalidate fs/namei.c:862 [inline]\n lookup_fast+0x89e/0x8e0 fs/namei.c:1649\n walk_component fs/namei.c:2001 [inline]\n link_path_walk+0x817/0x1480 fs/namei.c:2332\n path_lookupat+0xd9/0x6f0 fs/namei.c:2485\n filename_lookup+0x22e/0x740 fs/namei.c:2515\n user_path_at_empty+0x8b/0x390 fs/namei.c:2924\n user_path_at include/linux/namei.h:57 [inline]\n do_mount fs/namespace.c:3689 [inline]\n __do_sys_mount fs/namespace.c:3898 [inline]\n __se_sys_mount+0x66b/0x810 fs/namespace.c:3875\n __x64_sys_mount+0xe4/0x140 fs/namespace.c:3875\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nBUG: KMSAN: uninit-value in hfs_ext_read_extent fs/hfs/extent.c:196 [inline]\nBUG: KMSAN: uninit-value in hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366\n hfs_ext_read_extent fs/hfs/extent.c:196 [inline]\n hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366\n block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271\n hfs_read_folio+0x55/0x60 fs/hfs/inode.c:39\n filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426\n do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553\n do_read_cache_page mm/filemap.c:3595 [inline]\n read_cache_page+0xfb/0x2f0 mm/filemap.c:3604\n read_mapping_page include/linux/pagemap.h:755 [inline]\n hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78\n hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204\n hfs_fill_super+0x1fb1/0x2790 fs/hfs/super.c:406\n mount_bdev+0x628/0x920 fs/super.c:1359\n hfs_mount+0xcd/0xe0 fs/hfs/super.c:456\n legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610\n vfs_get_tree+0xdc/0x5d0 fs/super.c:1489\n do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145\n path_mount+0xf98/0x26a0 fs/namespace.c:3475\n do_mount fs/namespace.c:3488 [inline]\n __do_sys_mount fs/namespace.c:3697 [inline]\n __se_sys_mount+0x919/0x9e0 fs/namespace.c:3674\n __ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674\n do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]\n __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178\n do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246\n entry_SYSENTER_compat_after_hwframe+0x70/0x82\r\n\r\nUninit was created at:\n __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590\n __alloc_pages_node include/linux/gfp.h:238 [inline]\n alloc_pages_node include/linux/gfp.h:261 [inline]\n alloc_slab_page mm/slub.c:2190 [inline]\n allocate_slab mm/slub.c:2354 [inline]\n new_slab+0x2d7/0x1400 mm/slub.c:2407\n ___slab_alloc+0x16b5/0x3970 mm/slub.c:3540\n __slab_alloc mm/slub.c:3625 [inline]\n __slab_alloc_node mm/slub.c:3678 [inline]\n slab_alloc_node mm/slub.c:3850 [inline]\n kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879\n alloc_inode_sb include/linux/fs.h:3018 [inline]\n hfs_alloc_inode+0x5a/0xc0 fs/hfs/super.c:165\n alloc_inode+0x83/0x440 fs/inode.c:260\n new_inode_pseudo fs/inode.c:1005 [inline]\n new_inode+0x38/0x4f0 fs/inode.c:1031\n hfs_new_inode+0x61/0x1010 fs/hfs/inode.c:186\n hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228\n vfs_mkdir+0x49a/0x700 fs/namei.c:4126\n do_mkdirat+0x529/0x810 fs/namei.c:4149\n __do_sys_mkdirat fs/namei.c:4164 [inline]\n __se_sys_mkdirat fs/namei.c:4162 [inline]\n __x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nIt missed to initialize .tz_secondswest, .cached_start and .cached_blocks\nfields in struct hfs_inode_info after hfs_alloc_inode(), fix it.(CVE-2024-42311)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsysctl: always initialize i_uid/i_gid\r\n\r\nAlways initialize i_uid/i_gid inside the sysfs core so set_ownership()\ncan safely skip setting them.\r\n\r\nCommit 5ec27ec735ba (\u0026quot;fs/proc/proc_sysctl.c: fix the default values of\ni_uid/i_gid on /proc/sys inodes.\u0026quot;) added defaults for i_uid/i_gid when\nset_ownership() was not implemented. It also missed adjusting\nnet_ctl_set_ownership() to use the same default values in case the\ncomputation of a better value failed.(CVE-2024-42312)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: vhci-hcd: Do not drop references before new references are gained\r\n\r\nAt a few places the driver carries stale pointers\nto references that can still be used. Make sure that does not happen.\nThis strictly speaking closes ZDI-CAN-22273, though there may be\nsimilar races in the driver.(CVE-2024-43883)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntracing: Fix overflow in get_free_elt()\r\n\r\n\u0026quot;tracing_map-\u0026gt;next_elt\u0026quot; in get_free_elt() is at risk of overflowing.\r\n\r\nOnce it overflows, new elements can still be inserted into the tracing_map\neven though the maximum number of elements (`max_elts`) has been reached.\nContinuing to insert elements after the overflow could result in the\ntracing_map containing \u0026quot;tracing_map-\u0026gt;max_size\u0026quot; elements, leaving no empty\nentries.\nIf any attempt is made to insert an element into a full tracing_map using\n`__tracing_map_insert()`, it will cause an infinite loop with preemption\ndisabled, leading to a CPU hang problem.\r\n\r\nFix this by preventing any further increments to \u0026quot;tracing_map-\u0026gt;next_elt\u0026quot;\nonce it reaches \u0026quot;tracing_map-\u0026gt;max_elt\u0026quot;.(CVE-2024-43890)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: xc2028: avoid use-after-free in load_firmware_cb()\r\n\r\nsyzkaller reported use-after-free in load_firmware_cb() [1].\nThe reason is because the module allocated a struct tuner in tuner_probe(),\nand then the module initialization failed, the struct tuner was released.\nA worker which created during module initialization accesses this struct\ntuner later, it caused use-after-free.\r\n\r\nThe process is as follows:\r\n\r\ntask-6504           worker_thread\ntuner_probe                             \u0026lt;= alloc dvb_frontend [2]\n...\nrequest_firmware_nowait                 \u0026lt;= create a worker\n...\ntuner_remove                            \u0026lt;= free dvb_frontend\n...\n                    request_firmware_work_func  \u0026lt;= the firmware is ready\n                    load_firmware_cb    \u0026lt;= but now the dvb_frontend has been freed\r\n\r\nTo fix the issue, check the dvd_frontend in load_firmware_cb(), if it is\nnull, report a warning and just return.\r\n\r\n[1]:\n    ==================================================================\n     BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0\n     Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504\r\n\r\n     Call trace:\n      load_firmware_cb+0x1310/0x17a0\n      request_firmware_work_func+0x128/0x220\n      process_one_work+0x770/0x1824\n      worker_thread+0x488/0xea0\n      kthread+0x300/0x430\n      ret_from_fork+0x10/0x20\r\n\r\n     Allocated by task 6504:\n      kzalloc\n      tuner_probe+0xb0/0x1430\n      i2c_device_probe+0x92c/0xaf0\n      really_probe+0x678/0xcd0\n      driver_probe_device+0x280/0x370\n      __device_attach_driver+0x220/0x330\n      bus_for_each_drv+0x134/0x1c0\n      __device_attach+0x1f4/0x410\n      device_initial_probe+0x20/0x30\n      bus_probe_device+0x184/0x200\n      device_add+0x924/0x12c0\n      device_register+0x24/0x30\n      i2c_new_device+0x4e0/0xc44\n      v4l2_i2c_new_subdev_board+0xbc/0x290\n      v4l2_i2c_new_subdev+0xc8/0x104\n      em28xx_v4l2_init+0x1dd0/0x3770\r\n\r\n     Freed by task 6504:\n      kfree+0x238/0x4e4\n      tuner_remove+0x144/0x1c0\n      i2c_device_remove+0xc8/0x290\n      __device_release_driver+0x314/0x5fc\n      device_release_driver+0x30/0x44\n      bus_remove_device+0x244/0x490\n      device_del+0x350/0x900\n      device_unregister+0x28/0xd0\n      i2c_unregister_device+0x174/0x1d0\n      v4l2_device_unregister+0x224/0x380\n      em28xx_v4l2_init+0x1d90/0x3770\r\n\r\n     The buggy address belongs to the object at ffff8000d7ca2000\n      which belongs to the cache kmalloc-2k of size 2048\n     The buggy address is located 776 bytes inside of\n      2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)\n     The buggy address belongs to the page:\n     page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0\n     flags: 0x7ff800000000100(slab)\n     raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000\n     raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000\n     page dumped because: kasan: bad access detected\r\n\r\n     Memory state around the buggy address:\n      ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n      ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     \u0026gt;ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                           ^\n      ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n      ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     ==================================================================\r\n\r\n[2]\n    Actually, it is allocated for struct tuner, and dvb_frontend is inside.(CVE-2024-43900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: ctnetlink: use helper function to calculate expect ID\r\n\r\nDelete expectation path is missing a call to the nf_expect_get_id()\nhelper function to calculate the expectation ID, otherwise LSB of the\nexpectation object address is leaked to userspace.(CVE-2024-44944)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2409.1.0.0293.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm","kernel-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm","perf-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2409.1.0.0293.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm","kernel-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm","perf-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2109"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48877"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48891"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48908"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48937"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52899"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40901"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42131"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42286"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42292"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42311"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42312"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43883"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43890"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43900"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44944"}],"database_specific":{"severity":"High"}}