{"schema_version":"1.7.2","id":"OESA-2024-2079","modified":"2024-08-30T11:09:00Z","published":"2024-08-30T11:09:00Z","upstream":["CVE-2022-48795","CVE-2022-48899","CVE-2022-48924","CVE-2022-48928","CVE-2022-48943","CVE-2023-52893","CVE-2023-52898","CVE-2023-52900","CVE-2024-39501","CVE-2024-41015","CVE-2024-41068","CVE-2024-42153","CVE-2024-42265","CVE-2024-42271","CVE-2024-42280","CVE-2024-42284","CVE-2024-42285","CVE-2024-42289","CVE-2024-42297","CVE-2024-42305","CVE-2024-43861","CVE-2024-43879","CVE-2024-43882"],"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\nparisc: Fix data TLB miss in sba_unmap_sg\r\n\r\nRolf Eike Beer reported the following bug:\r\n\r\n[1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018\n[1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4\n[1274934.746891] Hardware name: 9000/785/C8000\n[1274934.746891]\n[1274934.746891]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI\n[1274934.746891] PSW: 00001000000001001111111000001110 Not tainted\n[1274934.746891] r00-03  000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000\n[1274934.746891] r04-07  0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001\n[1274934.746891] r08-11  0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001\n[1274934.746891] r12-15  0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0\n[1274934.746891] r16-19  0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007\n[1274934.746891] r20-23  0000000000000006 000000004a368950 0000000000000000 0000000000000001\n[1274934.746891] r24-27  0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0\n[1274934.746891] r28-31  0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118\n[1274934.746891] sr00-03  00000000066e5800 0000000000000000 0000000000000000 00000000066e5800\n[1274934.746891] sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000\n[1274934.746891]\n[1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec\n[1274934.746891]  IIR: 48780030    ISR: 0000000000000000  IOR: 0000004140000018\n[1274934.746891]  CPU:        3   CR30: 00000040e3a9c000 CR31: ffffffffffffffff\n[1274934.746891]  ORIG_R28: 0000000040acdd58\n[1274934.746891]  IAOQ[0]: sba_unmap_sg+0xb0/0x118\n[1274934.746891]  IAOQ[1]: sba_unmap_sg+0xb4/0x118\n[1274934.746891]  RP(r2): sba_unmap_sg+0xac/0x118\n[1274934.746891] Backtrace:\n[1274934.746891]  [\u0026lt;00000000402740cc\u0026gt;] dma_unmap_sg_attrs+0x6c/0x70\n[1274934.746891]  [\u0026lt;000000004074d6bc\u0026gt;] scsi_dma_unmap+0x54/0x60\n[1274934.746891]  [\u0026lt;00000000407a3488\u0026gt;] mptscsih_io_done+0x150/0xd70\n[1274934.746891]  [\u0026lt;0000000040798600\u0026gt;] mpt_interrupt+0x168/0xa68\n[1274934.746891]  [\u0026lt;0000000040255a48\u0026gt;] __handle_irq_event_percpu+0xc8/0x278\n[1274934.746891]  [\u0026lt;0000000040255c34\u0026gt;] handle_irq_event_percpu+0x3c/0xd8\n[1274934.746891]  [\u0026lt;000000004025ecb4\u0026gt;] handle_percpu_irq+0xb4/0xf0\n[1274934.746891]  [\u0026lt;00000000402548e0\u0026gt;] generic_handle_irq+0x50/0x70\n[1274934.746891]  [\u0026lt;000000004019a254\u0026gt;] call_on_stack+0x18/0x24\n[1274934.746891]\n[1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?)\r\n\r\nThe bug is caused by overrunning the sglist and incorrectly testing\nsg_dma_len(sglist) before nents. Normally this doesn\u0026apos;t cause a crash,\nbut in this case sglist crossed a page boundary. This occurs in the\nfollowing code:\r\n\r\n\twhile (sg_dma_len(sglist) \u0026amp;\u0026amp; nents--) {\r\n\r\nThe fix is simply to test nents first and move the decrement of nents\ninto the loop.(CVE-2022-48795)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/virtio: Fix GEM handle creation UAF\r\n\r\nUserspace can guess the handle value and try to race GEM object creation\nwith handle close, resulting in a use-after-free if we dereference the\nobject after dropping the handle\u0026apos;s reference.  For that reason, dropping\nthe handle\u0026apos;s reference must be done *after* we are done dereferencing\nthe object.(CVE-2022-48899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthermal: int340x: fix memory leak in int3400_notify()\r\n\r\nIt is easy to hit the below memory leaks in my TigerLake platform:\r\n\r\nunreferenced object 0xffff927c8b91dbc0 (size 32):\n  comm \u0026quot;kworker/0:2\u0026quot;, pid 112, jiffies 4294893323 (age 83.604s)\n  hex dump (first 32 bytes):\n    4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65  NAME=INT3400 The\n    72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  rmal.kkkkkkkkkk.\n  backtrace:\n    [\u0026lt;ffffffff9c502c3e\u0026gt;] __kmalloc_track_caller+0x2fe/0x4a0\n    [\u0026lt;ffffffff9c7b7c15\u0026gt;] kvasprintf+0x65/0xd0\n    [\u0026lt;ffffffff9c7b7d6e\u0026gt;] kasprintf+0x4e/0x70\n    [\u0026lt;ffffffffc04cb662\u0026gt;] int3400_notify+0x82/0x120 [int3400_thermal]\n    [\u0026lt;ffffffff9c8b7358\u0026gt;] acpi_ev_notify_dispatch+0x54/0x71\n    [\u0026lt;ffffffff9c88f1a7\u0026gt;] acpi_os_execute_deferred+0x17/0x30\n    [\u0026lt;ffffffff9c2c2c0a\u0026gt;] process_one_work+0x21a/0x3f0\n    [\u0026lt;ffffffff9c2c2e2a\u0026gt;] worker_thread+0x4a/0x3b0\n    [\u0026lt;ffffffff9c2cb4dd\u0026gt;] kthread+0xfd/0x130\n    [\u0026lt;ffffffff9c201c1f\u0026gt;] ret_from_fork+0x1f/0x30\r\n\r\nFix it by calling kfree() accordingly.(CVE-2022-48924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niio: adc: men_z188_adc: Fix a resource leak in an error handling path\r\n\r\nIf iio_device_register() fails, a previous ioremap() is left unbalanced.\r\n\r\nUpdate the error handling path and add the missing iounmap() call, as\nalready done in the remove function.(CVE-2022-48928)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: x86/mmu: make apf token non-zero to fix bug\r\n\r\nIn current async pagefault logic, when a page is ready, KVM relies on\nkvm_arch_can_dequeue_async_page_present() to determine whether to deliver\na READY event to the Guest. This function test token value of struct\nkvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when a\nREADY event is finished by Guest. If value is zero meaning that a READY\nevent is done, so the KVM can deliver another.\nBut the kvm_arch_setup_async_pf() may produce a valid token with zero\nvalue, which is confused with previous mention and may lead the loss of\nthis READY event.\r\n\r\nThis bug may cause task blocked forever in Guest:\n INFO: task stress:7532 blocked for more than 1254 seconds.\n       Not tainted 5.10.0 #16\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:stress          state:D stack:    0 pid: 7532 ppid:  1409\n flags:0x00000080\n Call Trace:\n  __schedule+0x1e7/0x650\n  schedule+0x46/0xb0\n  kvm_async_pf_task_wait_schedule+0xad/0xe0\n  ? exit_to_user_mode_prepare+0x60/0x70\n  __kvm_handle_async_pf+0x4f/0xb0\n  ? asm_exc_page_fault+0x8/0x30\n  exc_page_fault+0x6f/0x110\n  ? asm_exc_page_fault+0x8/0x30\n  asm_exc_page_fault+0x1e/0x30\n RIP: 0033:0x402d00\n RSP: 002b:00007ffd31912500 EFLAGS: 00010206\n RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0\n RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0\n RBP: 00000000021262b0 R08: 0000000000000003 R09: 0000000000000086\n R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000\n R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000(CVE-2022-48943)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngsmi: fix null-deref in gsmi_get_variable\r\n\r\nWe can get EFI variables without fetching the attribute, so we must\nallow for that in gsmi.\r\n\r\ncommit 859748255b43 (\u0026quot;efi: pstore: Omit efivars caching EFI varstore\naccess layer\u0026quot;) added a new get_variable call with attr=NULL, which\ntriggers panic in gsmi.(CVE-2023-52893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxhci: Fix null pointer dereference when host dies\r\n\r\nMake sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race\nand cause null pointer dereference when host suddenly dies.\r\n\r\nUsb core may call xhci_free_dev() which frees the xhci-\u0026gt;devs[slot_id]\nvirt device at the same time that xhci_kill_endpoint_urbs() tries to\nloop through all the device\u0026apos;s endpoints, checking if there are any\ncancelled urbs left to give back.\r\n\r\nhold the xhci spinlock while freeing the virt device(CVE-2023-52898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix general protection fault in nilfs_btree_insert()\r\n\r\nIf nilfs2 reads a corrupted disk image and tries to reads a b-tree node\nblock by calling __nilfs_btree_get_block() against an invalid virtual\nblock address, it returns -ENOENT because conversion of the virtual block\naddress to a disk block address fails.  However, this return value is the\nsame as the internal code that b-tree lookup routines return to indicate\nthat the block being searched does not exist, so functions that operate on\nthat b-tree may misbehave.\r\n\r\nWhen nilfs_btree_insert() receives this spurious \u0026apos;not found\u0026apos; code from\nnilfs_btree_do_lookup(), it misunderstands that the \u0026apos;not found\u0026apos; check was\nsuccessful and continues the insert operation using incomplete lookup path\ndata, causing the following crash:\r\n\r\n general protection fault, probably for non-canonical address\n 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN\n KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n ...\n RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]\n RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]\n RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238\n Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89\n ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 \u0026lt;42\u0026gt; 80 3c\n 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n  nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]\n  nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147\n  nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101\n  __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991\n  __block_write_begin fs/buffer.c:2041 [inline]\n  block_write_begin+0x93/0x1e0 fs/buffer.c:2102\n  nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261\n  generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772\n  __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900\n  generic_file_write_iter+0xab/0x310 mm/filemap.c:3932\n  call_write_iter include/linux/fs.h:2186 [inline]\n  new_sync_write fs/read_write.c:491 [inline]\n  vfs_write+0x7dc/0xc50 fs/read_write.c:584\n  ksys_write+0x177/0x2a0 fs/read_write.c:637\n  do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n  do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n ...\n \u0026lt;/TASK\u0026gt;\r\n\r\nThis patch fixes the root cause of this problem by replacing the error\ncode that __nilfs_btree_get_block() returns on block address conversion\nfailure from -ENOENT to another internal code -EINVAL which means that the\nb-tree metadata is corrupted.\r\n\r\nBy returning -EINVAL, it propagates without glitches, and for all relevant\nb-tree operations, functions in the upper bmap layer output an error\nmessage indicating corrupted b-tree metadata via\nnilfs_bmap_convert_error(), and code -EIO will be eventually returned as\nit should be.(CVE-2023-52900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers: core: synchronize really_probe() and dev_uevent()\r\n\r\nSynchronize the dev-\u0026gt;driver usage in really_probe() and dev_uevent().\nThese can run in different threads, what can result in the following\nrace condition for dev-\u0026gt;driver uninitialization:\r\n\r\nThread #1:\n==========\r\n\r\nreally_probe() {\n...\nprobe_failed:\n...\ndevice_unbind_cleanup(dev) {\n    ...\n    dev-\u0026gt;driver = NULL;   // \u0026lt;= Failed probe sets dev-\u0026gt;driver to NULL\n    ...\n    }\n...\n}\r\n\r\nThread #2:\n==========\r\n\r\ndev_uevent() {\n...\nif (dev-\u0026gt;driver)\n      // If dev-\u0026gt;driver is NULLed from really_probe() from here on,\n      // after above check, the system crashes\n      add_uevent_var(env, \u0026quot;DRIVER=%s\u0026quot;, dev-\u0026gt;driver-\u0026gt;name);\n...\n}\r\n\r\nreally_probe() holds the lock, already. So nothing needs to be done\nthere. dev_uevent() is called with lock held, often, too. But not\nalways. What implies that we can\u0026apos;t add any locking in dev_uevent()\nitself. So fix this race by adding the lock to the non-protected\npath. This is the path where above race is observed:\r\n\r\n dev_uevent+0x235/0x380\n uevent_show+0x10c/0x1f0  \u0026lt;= Add lock here\n dev_attr_show+0x3a/0xa0\n sysfs_kf_seq_show+0x17c/0x250\n kernfs_seq_show+0x7c/0x90\n seq_read_iter+0x2d7/0x940\n kernfs_fop_read_iter+0xc6/0x310\n vfs_read+0x5bc/0x6b0\n ksys_read+0xeb/0x1b0\n __x64_sys_read+0x42/0x50\n x64_sys_call+0x27ad/0x2d30\n do_syscall_64+0xcd/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nSimilar cases are reported by syzkaller in\r\n\r\nhttps://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a\r\n\r\nBut these are regarding the *initialization* of dev-\u0026gt;driver\r\n\r\ndev-\u0026gt;driver = drv;\r\n\r\nAs this switches dev-\u0026gt;driver to non-NULL these reports can be considered\nto be false-positives (which should be \u0026quot;fixed\u0026quot; by this commit, as well,\nthough).\r\n\r\nThe same issue was reported and tried to be fixed back in 2015 in\r\n\r\nhttps://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/\r\n\r\nalready.(CVE-2024-39501)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: add bounds checking to ocfs2_check_dir_entry()\r\n\r\nThis adds sanity checks for ocfs2_dir_entry to make sure all members of\nocfs2_dir_entry don\u0026apos;t stray beyond valid memory region.(CVE-2024-41015)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/sclp: Fix sclp_init() cleanup on failure\r\n\r\nIf sclp_init() fails it only partially cleans up: if there are multiple\nfailing calls to sclp_init() sclp_state_change_event will be added several\ntimes to sclp_reg_list, which results in the following warning:\r\n\r\n------------[ cut here ]------------\nlist_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10.\nWARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8\nCPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3\nKrnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8)\n           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3\n...\nCall Trace:\n [\u0026lt;000003ffe0d6076a\u0026gt;] __list_add_valid_or_report+0xe2/0xf8\n([\u0026lt;000003ffe0d60766\u0026gt;] __list_add_valid_or_report+0xde/0xf8)\n [\u0026lt;000003ffe0a8d37e\u0026gt;] sclp_init+0x40e/0x450\n [\u0026lt;000003ffe00009f2\u0026gt;] do_one_initcall+0x42/0x1e0\n [\u0026lt;000003ffe15b77a6\u0026gt;] do_initcalls+0x126/0x150\n [\u0026lt;000003ffe15b7a0a\u0026gt;] kernel_init_freeable+0x1ba/0x1f8\n [\u0026lt;000003ffe0d6650e\u0026gt;] kernel_init+0x2e/0x180\n [\u0026lt;000003ffe000301c\u0026gt;] __ret_from_fork+0x3c/0x60\n [\u0026lt;000003ffe0d759ca\u0026gt;] ret_from_fork+0xa/0x30\r\n\r\nFix this by removing sclp_state_change_event from sclp_reg_list when\nsclp_init() fails.(CVE-2024-41068)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr\r\n\r\nWhen del_timer_sync() is called in an interrupt context it throws a warning\nbecause of potential deadlock. The timer is used only to exit from\nwait_for_completion() after a timeout so replacing the call with\nwait_for_completion_timeout() allows to remove the problematic timer and\nits related functions altogether.(CVE-2024-42153)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nprotect the fetch of -\u0026gt;fd[fd] in do_dup2() from mispredictions\r\n\r\nboth callers have verified that fd is not greater than -\u0026gt;max_fds;\nhowever, misprediction might end up with\n        tofree = fdt-\u0026gt;fd[fd];\nbeing speculatively executed.  That\u0026apos;s wrong for the same reasons\nwhy it\u0026apos;s wrong in close_fd()/file_close_fd_locked(); the same\nsolution applies - array_index_nospec(fd, fdt-\u0026gt;max_fds) could differ\nfrom fd only in case of speculative execution on mispredicted path.(CVE-2024-42265)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/iucv: fix use after free in iucv_sock_close()\r\n\r\niucv_sever_path() is called from process context and from bh context.\niucv-\u0026gt;path is used as indicator whether somebody else is taking care of\nsevering the path (or it is already removed / never existed).\nThis needs to be done with atomic compare and swap, otherwise there is a\nsmall window where iucv_sock_close() will try to work with a path that has\nalready been severed and freed by iucv_callback_connrej() called by\niucv_tasklet_fn().\r\n\r\nExample:\n[452744.123844] Call Trace:\n[452744.123845] ([\u0026lt;0000001e87f03880\u0026gt;] 0x1e87f03880)\n[452744.123966]  [\u0026lt;00000000d593001e\u0026gt;] iucv_path_sever+0x96/0x138\n[452744.124330]  [\u0026lt;000003ff801ddbca\u0026gt;] iucv_sever_path+0xc2/0xd0 [af_iucv]\n[452744.124336]  [\u0026lt;000003ff801e01b6\u0026gt;] iucv_sock_close+0xa6/0x310 [af_iucv]\n[452744.124341]  [\u0026lt;000003ff801e08cc\u0026gt;] iucv_sock_release+0x3c/0xd0 [af_iucv]\n[452744.124345]  [\u0026lt;00000000d574794e\u0026gt;] __sock_release+0x5e/0xe8\n[452744.124815]  [\u0026lt;00000000d5747a0c\u0026gt;] sock_close+0x34/0x48\n[452744.124820]  [\u0026lt;00000000d5421642\u0026gt;] __fput+0xba/0x268\n[452744.124826]  [\u0026lt;00000000d51b382c\u0026gt;] task_work_run+0xbc/0xf0\n[452744.124832]  [\u0026lt;00000000d5145710\u0026gt;] do_notify_resume+0x88/0x90\n[452744.124841]  [\u0026lt;00000000d5978096\u0026gt;] system_call+0xe2/0x2c8\n[452744.125319] Last Breaking-Event-Address:\n[452744.125321]  [\u0026lt;00000000d5930018\u0026gt;] iucv_path_sever+0x90/0x138\n[452744.125324]\n[452744.125325] Kernel panic - not syncing: Fatal exception in interrupt\r\n\r\nNote that bh_lock_sock() is not serializing the tasklet context against\nprocess context, because the check for sock_owned_by_user() and\ncorresponding handling is missing.\r\n\r\nIdeas for a future clean-up patch:\nA) Correct usage of bh_lock_sock() in tasklet context, as described in\nRe-enqueue, if needed. This may require adding return values to the\ntasklet functions and thus changes to all users of iucv.\r\n\r\nB) Change iucv tasklet into worker and use only lock_sock() in af_iucv.(CVE-2024-42271)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmISDN: Fix a use after free in hfcmulti_tx()\r\n\r\nDon\u0026apos;t dereference *sp after calling dev_kfree_skb(*sp).(CVE-2024-42280)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: Return non-zero value from tipc_udp_addr2str() on error\r\n\r\ntipc_udp_addr2str() should return non-zero value if the UDP media\naddress is invalid. Otherwise, a buffer overflow access can occur in\ntipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP\nmedia address.(CVE-2024-42284)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/iwcm: Fix a use-after-free related to destroying CM IDs\r\n\r\niw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with\nan existing struct iw_cm_id (cm_id) as follows:\r\n\r\n        conn_id-\u0026gt;cm_id.iw = cm_id;\n        cm_id-\u0026gt;context = conn_id;\n        cm_id-\u0026gt;cm_handler = cma_iw_handler;\r\n\r\nrdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make\nsure that cm_work_handler() does not trigger a use-after-free by only\nfreeing of the struct rdma_id_private after all pending work has finished.(CVE-2024-42285)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: During vport delete send async logout explicitly\r\n\r\nDuring vport delete, it is observed that during unload we hit a crash\nbecause of stale entries in outstanding command array.  For all these stale\nI/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but\nI/Os could not complete while vport delete is in process of deleting.\r\n\r\n  BUG: kernel NULL pointer dereference, address: 000000000000001c\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 0 P4D 0\n  Oops: 0000 [#1] PREEMPT SMP NOPTI\n  Workqueue: qla2xxx_wq qla_do_work [qla2xxx]\n  RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0\n  RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046\n  RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001\n  RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0\n  RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8\n  R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000\n  R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000\n  FS:  0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0\n  Call Trace:\n  \u0026lt;TASK\u0026gt;\n  qla2xxx_qpair_sp_free_dma+0x417/0x4e0\n  ? qla2xxx_qpair_sp_compl+0x10d/0x1a0\n  ? qla2x00_status_entry+0x768/0x2830\n  ? newidle_balance+0x2f0/0x430\n  ? dequeue_entity+0x100/0x3c0\n  ? qla24xx_process_response_queue+0x6a1/0x19e0\n  ? __schedule+0x2d5/0x1140\n  ? qla_do_work+0x47/0x60\n  ? process_one_work+0x267/0x440\n  ? process_one_work+0x440/0x440\n  ? worker_thread+0x2d/0x3d0\n  ? process_one_work+0x440/0x440\n  ? kthread+0x156/0x180\n  ? set_kthread_struct+0x50/0x50\n  ? ret_from_fork+0x22/0x30\n  \u0026lt;/TASK\u0026gt;\r\n\r\nSend out async logout explicitly for all the ports during vport delete.(CVE-2024-42289)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to don\u0026apos;t dirty inode for readonly filesystem\r\n\r\nsyzbot reports f2fs bug as below:\r\n\r\nkernel BUG at fs/f2fs/inode.c:933!\nRIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933\nCall Trace:\n evict+0x2a4/0x620 fs/inode.c:664\n dispose_list fs/inode.c:697 [inline]\n evict_inodes+0x5f8/0x690 fs/inode.c:747\n generic_shutdown_super+0x9d/0x2c0 fs/super.c:675\n kill_block_super+0x44/0x90 fs/super.c:1667\n kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894\n deactivate_locked_super+0xc1/0x130 fs/super.c:484\n cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256\n task_work_run+0x24a/0x300 kernel/task_work.c:180\n ptrace_notify+0x2cd/0x380 kernel/signal.c:2399\n ptrace_report_syscall include/linux/ptrace.h:411 [inline]\n ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline]\n syscall_exit_work kernel/entry/common.c:251 [inline]\n syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline]\n syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296\n do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nThe root cause is:\n- do_sys_open\n - f2fs_lookup\n  - __f2fs_find_entry\n   - f2fs_i_depth_write\n    - f2fs_mark_inode_dirty_sync\n     - f2fs_dirty_inode\n      - set_inode_flag(inode, FI_DIRTY_INODE)\r\n\r\n- umount\n - kill_f2fs_super\n  - kill_block_super\n   - generic_shutdown_super\n    - sync_filesystem\n    : sb is readonly, skip sync_filesystem()\n    - evict_inodes\n     - iput\n      - f2fs_evict_inode\n       - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE))\n       : trigger kernel panic\r\n\r\nWhen we try to repair i_current_depth in readonly filesystem, let\u0026apos;s\nskip dirty inode to avoid panic in later f2fs_evict_inode().(CVE-2024-42297)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: check dot and dotdot of dx_root before making dir indexed\r\n\r\nSyzbot reports a issue as follows:\n============================================\nBUG: unable to handle page fault for address: ffffed11022e24fe\nPGD 23ffee067 P4D 23ffee067 PUD 0\nOops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341\n ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451\n ext4_rename fs/ext4/namei.c:3936 [inline]\n ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214\n[...]\n============================================\r\n\r\nThe immediate cause of this problem is that there is only one valid dentry\nfor the block to be split during do_split, so split==0 results in out of\nbounds accesses to the map triggering the issue.\r\n\r\n    do_split\n      unsigned split\n      dx_make_map\n       count = 1\n      split = count/2 = 0;\n      continued = hash2 == map[split - 1].hash;\n       ---\u0026gt; map[4294967295]\r\n\r\nThe maximum length of a filename is 255 and the minimum block size is 1024,\nso it is always guaranteed that the number of entries is greater than or\nequal to 2 when do_split() is called.\r\n\r\nBut syzbot\u0026apos;s crafted image has no dot and dotdot in dir, and the dentry\ndistribution in dirblock is as follows:\r\n\r\n  bus     dentry1          hole           dentry2           free\n|xx--|xx-------------|...............|xx-------------|...............|\n0   12 (8+248)=256  268     256     524 (8+256)=264 788     236     1024\r\n\r\nSo when renaming dentry1 increases its name_len length by 1, neither hole\nnor free is sufficient to hold the new dentry, and make_indexed_dir() is\ncalled.\r\n\r\nIn make_indexed_dir() it is assumed that the first two entries of the\ndirblock must be dot and dotdot, so bus and dentry1 are left in dx_root\nbecause they are treated as dot and dotdot, and only dentry2 is moved\nto the new leaf block. That\u0026apos;s why count is equal to 1.\r\n\r\nTherefore add the ext4_check_dx_root() helper function to add more sanity\nchecks to dot and dotdot before starting the conversion to avoid the above\nissue.(CVE-2024-42305)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: usb: qmi_wwan: fix memory leak for not ip packets\r\n\r\nFree the unused skb when not ip packets arrive.(CVE-2024-43861)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()\r\n\r\nCurrently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in\ncfg80211_calculate_bitrate_he(), leading to below warning:\r\n\r\nkernel: invalid HE MCS: bw:6, ru:6\nkernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]\r\n\r\nFix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.(CVE-2024-43879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nexec: Fix ToCToU between perm check and set-uid/gid usage\r\n\r\nWhen opening a file for exec via do_filp_open(), permission checking is\ndone against the file\u0026apos;s metadata at that moment, and on success, a file\npointer is passed back. Much later in the execve() code path, the file\nmetadata (specifically mode, uid, and gid) is used to determine if/how\nto set the uid and gid. However, those values may have changed since the\npermissions check, meaning the execution may gain unintended privileges.\r\n\r\nFor example, if a file could change permissions from executable and not\nset-id:\r\n\r\n---------x 1 root root 16048 Aug  7 13:16 target\r\n\r\nto set-id and non-executable:\r\n\r\n---S------ 1 root root 16048 Aug  7 13:16 target\r\n\r\nit is possible to gain root privileges when execution should have been\ndisallowed.\r\n\r\nWhile this race condition is rare in real-world scenarios, it has been\nobserved (and proven exploitable) when package managers are updating\nthe setuid bits of installed programs. Such files start with being\nworld-executable but then are adjusted to be group-exec with a set-uid\nbit. For example, \u0026quot;chmod o-x,u+s target\u0026quot; makes \u0026quot;target\u0026quot; executable only\nby uid \u0026quot;root\u0026quot; and gid \u0026quot;cdrom\u0026quot;, while also becoming setuid-root:\r\n\r\n-rwxr-xr-x 1 root cdrom 16048 Aug  7 13:16 target\r\n\r\nbecomes:\r\n\r\n-rwsr-xr-- 1 root cdrom 16048 Aug  7 13:16 target\r\n\r\nBut racing the chmod means users without group \u0026quot;cdrom\u0026quot; membership can\nget the permission to execute \u0026quot;target\u0026quot; just before the chmod, and when\nthe chmod finishes, the exec reaches brpm_fill_uid(), and performs the\nsetuid to root, violating the expressed authorization of \u0026quot;only cdrom\ngroup members can setuid to root\u0026quot;.\r\n\r\nRe-check that we still have execute permissions in case the metadata\nhas changed. It would be better to keep a copy from the perm-check time,\nbut until we can do that refactoring, the least-bad option is to do a\nfull inode_permission() call (under inode lock). It is understood that\nthis is safe against dead-locks, but hardly optimal.(CVE-2024-43882)","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-2408.5.0.0292.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm","kernel-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm","perf-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2408.5.0.0292.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm","kernel-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm","perf-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2079"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48795"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48899"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48924"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48928"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48943"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52893"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52898"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52900"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-39501"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41015"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41068"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42153"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42265"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42271"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42280"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42284"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42285"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42289"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42297"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42305"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43861"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43879"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43882"}],"database_specific":{"severity":"High"}}