{"schema_version":"1.7.2","id":"OESA-2024-2182","modified":"2024-09-27T11:09:13Z","published":"2024-09-27T11:09:13Z","upstream":["CVE-2021-47205","CVE-2022-48828","CVE-2024-35837","CVE-2024-39501","CVE-2024-40978","CVE-2024-40980","CVE-2024-41017","CVE-2024-41098","CVE-2024-42104","CVE-2024-42119","CVE-2024-42292","CVE-2024-43846","CVE-2024-43863","CVE-2024-44939","CVE-2024-44965","CVE-2024-44995","CVE-2024-44999","CVE-2024-45003","CVE-2024-45025","CVE-2024-45028","CVE-2024-46714","CVE-2024-46723","CVE-2024-46731","CVE-2024-46733","CVE-2024-46742","CVE-2024-46744","CVE-2024-46745","CVE-2024-46747","CVE-2024-46751","CVE-2024-46752","CVE-2024-46787","CVE-2024-46800"],"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\nclk: sunxi-ng: Unregister clocks/resets when unbinding\r\n\r\nCurrently, unbinding a CCU driver unmaps the device\u0026apos;s MMIO region, while\nleaving its clocks/resets and their providers registered. This can cause\na page fault later when some clock operation tries to perform MMIO. Fix\nthis by separating the CCU initialization from the memory allocation,\nand then using a devres callback to unregister the clocks and resets.\r\n\r\nThis also fixes a memory leak of the `struct ccu_reset`, and uses the\ncorrect owner (the specific platform driver) for the clocks and resets.\r\n\r\nEarly OF clock providers are never unregistered, and limited error\nhandling is possible, so they are mostly unchanged. The error reporting\nis made more consistent by moving the message inside of_sunxi_ccu_probe.(CVE-2021-47205)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNFSD: Fix ia_size underflow\r\n\r\niattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and\nNFSv4 both define file size as an unsigned 64-bit type. Thus there\nis a range of valid file size values an NFS client can send that is\nalready larger than Linux can handle.\r\n\r\nCurrently decode_fattr4() dumps a full u64 value into ia_size. If\nthat value happens to be larger than S64_MAX, then ia_size\nunderflows. I\u0026apos;m about to fix up the NFSv3 behavior as well, so let\u0026apos;s\ncatch the underflow in the common code path: nfsd_setattr().(CVE-2022-48828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: mvpp2: clear BM pool before initialization\r\n\r\nRegister value persist after booting the kernel using\nkexec which results in kernel panic. Thus clear the\nBM pool registers before initialisation to fix the issue.(CVE-2024-35837)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers: core: synchronize really_probe() and dev_uevent()\r\n\r\nSynchronize the dev-\u0026gt;driver usage in really_probe() and dev_uevent().\nThese can run in different threads, what can result in the following\nrace condition for dev-\u0026gt;driver uninitialization:\r\n\r\nThread #1:\n==========\r\n\r\nreally_probe() {\n...\nprobe_failed:\n...\ndevice_unbind_cleanup(dev) {\n    ...\n    dev-\u0026gt;driver = NULL;   // \u0026lt;= Failed probe sets dev-\u0026gt;driver to NULL\n    ...\n    }\n...\n}\r\n\r\nThread #2:\n==========\r\n\r\ndev_uevent() {\n...\nif (dev-\u0026gt;driver)\n      // If dev-\u0026gt;driver is NULLed from really_probe() from here on,\n      // after above check, the system crashes\n      add_uevent_var(env, \u0026quot;DRIVER=%s\u0026quot;, dev-\u0026gt;driver-\u0026gt;name);\n...\n}\r\n\r\nreally_probe() holds the lock, already. So nothing needs to be done\nthere. dev_uevent() is called with lock held, often, too. But not\nalways. What implies that we can\u0026apos;t add any locking in dev_uevent()\nitself. So fix this race by adding the lock to the non-protected\npath. This is the path where above race is observed:\r\n\r\n dev_uevent+0x235/0x380\n uevent_show+0x10c/0x1f0  \u0026lt;= Add lock here\n dev_attr_show+0x3a/0xa0\n sysfs_kf_seq_show+0x17c/0x250\n kernfs_seq_show+0x7c/0x90\n seq_read_iter+0x2d7/0x940\n kernfs_fop_read_iter+0xc6/0x310\n vfs_read+0x5bc/0x6b0\n ksys_read+0xeb/0x1b0\n __x64_sys_read+0x42/0x50\n x64_sys_call+0x27ad/0x2d30\n do_syscall_64+0xcd/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nSimilar cases are reported by syzkaller in\r\n\r\nhttps://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a\r\n\r\nBut these are regarding the *initialization* of dev-\u0026gt;driver\r\n\r\ndev-\u0026gt;driver = drv;\r\n\r\nAs this switches dev-\u0026gt;driver to non-NULL these reports can be considered\nto be false-positives (which should be \u0026quot;fixed\u0026quot; by this commit, as well,\nthough).\r\n\r\nThe same issue was reported and tried to be fixed back in 2015 in\r\n\r\nhttps://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/\r\n\r\nalready.(CVE-2024-39501)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qedi: Fix crash while reading debugfs attribute\r\n\r\nThe qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly\non a __user pointer, which results into the crash.\r\n\r\nTo fix this issue, use a small local stack buffer for sprintf() and then\ncall simple_read_from_buffer(), which in turns make the copy_to_user()\ncall.\r\n\r\nBUG: unable to handle page fault for address: 00007f4801111000\nPGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0\nOops: 0002 [#1] PREEMPT SMP PTI\nHardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023\nRIP: 0010:memcpy_orig+0xcd/0x130\nRSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202\nRAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f\nRDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000\nRBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572\nR10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff\nR13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af\nFS:  00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x183/0x510\n ? exc_page_fault+0x69/0x150\n ? asm_exc_page_fault+0x22/0x30\n ? memcpy_orig+0xcd/0x130\n vsnprintf+0x102/0x4c0\n sprintf+0x51/0x80\n qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]\n full_proxy_read+0x50/0x80\n vfs_read+0xa5/0x2e0\n ? folio_add_new_anon_rmap+0x44/0xa0\n ? set_pte_at+0x15/0x30\n ? do_pte_missing+0x426/0x7f0\n ksys_read+0xa5/0xe0\n do_syscall_64+0x58/0x80\n ? __count_memcg_events+0x46/0x90\n ? count_memcg_event_mm+0x3d/0x60\n ? handle_mm_fault+0x196/0x2f0\n ? do_user_addr_fault+0x267/0x890\n ? exc_page_fault+0x69/0x150\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7f4800f20b4d(CVE-2024-40978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrop_monitor: replace spin_lock by raw_spin_lock\r\n\r\ntrace_drop_common() is called with preemption disabled, and it acquires\na spin_lock. This is problematic for RT kernels because spin_locks are\nsleeping locks in this configuration, which causes the following splat:\r\n\r\nBUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\nin_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47\npreempt_count: 1, expected: 0\nRCU nest depth: 2, expected: 2\n5 locks held by rcuc/47/449:\n #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210\n #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130\n #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210\n #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70\n #4: ff1100086ee07520 (\u0026amp;data-\u0026gt;lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290\nirq event stamp: 139909\nhardirqs last  enabled at (139908): [\u0026lt;ffffffffb1df2b33\u0026gt;] _raw_spin_unlock_irqrestore+0x63/0x80\nhardirqs last disabled at (139909): [\u0026lt;ffffffffb19bd03d\u0026gt;] trace_drop_common.constprop.0+0x26d/0x290\nsoftirqs last  enabled at (139892): [\u0026lt;ffffffffb07a1083\u0026gt;] __local_bh_enable_ip+0x103/0x170\nsoftirqs last disabled at (139898): [\u0026lt;ffffffffb0909b33\u0026gt;] rcu_cpu_kthread+0x93/0x1f0\nPreemption disabled at:\n[\u0026lt;ffffffffb1de786b\u0026gt;] rt_mutex_slowunlock+0xab/0x2e0\nCPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7\nHardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x8c/0xd0\n dump_stack+0x14/0x20\n __might_resched+0x21e/0x2f0\n rt_spin_lock+0x5e/0x130\n ? trace_drop_common.constprop.0+0xb5/0x290\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n trace_drop_common.constprop.0+0xb5/0x290\n ? preempt_count_sub+0x1c/0xd0\n ? _raw_spin_unlock_irqrestore+0x4a/0x80\n ? __pfx_trace_drop_common.constprop.0+0x10/0x10\n ? rt_mutex_slowunlock+0x26a/0x2e0\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n ? __pfx_rt_mutex_slowunlock+0x10/0x10\n ? skb_queue_purge_reason.part.0+0x1bf/0x230\n trace_kfree_skb_hit+0x15/0x20\n trace_kfree_skb+0xe9/0x150\n kfree_skb_reason+0x7b/0x110\n skb_queue_purge_reason.part.0+0x1bf/0x230\n ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10\n ? mark_lock.part.0+0x8a/0x520\n...\r\n\r\ntrace_drop_common() also disables interrupts, but this is a minor issue\nbecause we could easily replace it with a local_lock.\r\n\r\nReplace the spin_lock with raw_spin_lock to avoid sleeping in atomic\ncontext.(CVE-2024-40980)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: don\u0026apos;t walk off the end of ealist\r\n\r\nAdd a check before visiting the members of ea to\nmake sure each ea stays within the ealist.(CVE-2024-41017)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nata: libata-core: Fix null pointer dereference on error\r\n\r\nIf the ata_port_alloc() call in ata_host_alloc() fails,\nata_host_release() will get called.\r\n\r\nHowever, the code in ata_host_release() tries to free ata_port struct\nmembers unconditionally, which can lead to the following:\r\n\r\nBUG: unable to handle page fault for address: 0000000000003990\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:ata_host_release.cold+0x2f/0x6e [libata]\nCode: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41\nRSP: 0018:ffffc90000ebb968 EFLAGS: 00010246\nRAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0\nRBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68\nR10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004\nR13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006\nFS:  00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die_body.cold+0x19/0x27\n ? page_fault_oops+0x15a/0x2f0\n ? exc_page_fault+0x7e/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? ata_host_release.cold+0x2f/0x6e [libata]\n ? ata_host_release.cold+0x2f/0x6e [libata]\n release_nodes+0x35/0xb0\n devres_release_group+0x113/0x140\n ata_host_alloc+0xed/0x120 [libata]\n ata_host_alloc_pinfo+0x14/0xa0 [libata]\n ahci_init_one+0x6c9/0xd20 [ahci]\r\n\r\nDo not access ata_port struct members unconditionally.(CVE-2024-41098)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: add missing check for inode numbers on directory entries\r\n\r\nSyzbot reported that mounting and unmounting a specific pattern of\ncorrupted nilfs2 filesystem images causes a use-after-free of metadata\nfile inodes, which triggers a kernel bug in lru_add_fn().\r\n\r\nAs Jan Kara pointed out, this is because the link count of a metadata file\ngets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),\ntries to delete that inode (ifile inode in this case).\r\n\r\nThe inconsistency occurs because directories containing the inode numbers\nof these metadata files that should not be visible in the namespace are\nread without checking.\r\n\r\nFix this issue by treating the inode numbers of these internal files as\nerrors in the sanity check helper when reading directory folios/pages.\r\n\r\nAlso thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer\nanalysis.(CVE-2024-42104)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip finding free audio for unknown engine_id\r\n\r\n[WHY]\nENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it\nalso means it is uninitialized and does not need free audio.\r\n\r\n[HOW]\nSkip and return NULL.\r\n\r\nThis fixes 2 OVERRUN issues reported by Coverity.(CVE-2024-42119)\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\nlib: objagg: Fix general protection fault\r\n\r\nThe library supports aggregation of objects into other objects only if\nthe parent object does not have a parent itself. That is, nesting is not\nsupported.\r\n\r\nAggregation happens in two cases: Without and with hints, where hints\nare a pre-computed recommendation on how to aggregate the provided\nobjects.\r\n\r\nNesting is not possible in the first case due to a check that prevents\nit, but in the second case there is no check because the assumption is\nthat nesting cannot happen when creating objects based on hints. The\nviolation of this assumption leads to various warnings and eventually to\na general protection fault [1].\r\n\r\nBefore fixing the root cause, error out when nesting happens and warn.\r\n\r\n[1]\ngeneral protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI\nCPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G        W          6.9.0-rc6-custom-gd9b4f1cca7fb #7\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n mlxsw_sp_acl_atcam_entry_add+0x256/0x3c0\n mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0\n mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270\n mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510\n process_one_work+0x151/0x370\n worker_thread+0x2cb/0x3e0\n kthread+0xd0/0x100\n ret_from_fork+0x34/0x50\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;(CVE-2024-43846)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/vmwgfx: Fix a deadlock in dma buf fence polling\r\n\r\nIntroduce a version of the fence ops that on release doesn\u0026apos;t remove\nthe fence from the pending list, and thus doesn\u0026apos;t require a lock to\nfix poll-\u0026gt;fence wait-\u0026gt;fence unref deadlocks.\r\n\r\nvmwgfx overwrites the wait callback to iterate over the list of all\nfences and update their status, to do that it holds a lock to prevent\nthe list modifcations from other threads. The fence destroy callback\nboth deletes the fence and removes it from the list of pending\nfences, for which it holds a lock.\r\n\r\ndma buf polling cb unrefs a fence after it\u0026apos;s been signaled: so the poll\ncalls the wait, which signals the fences, which are being destroyed.\nThe destruction tries to acquire the lock on the pending fences list\nwhich it can never get because it\u0026apos;s held by the wait from which it\nwas called.\r\n\r\nOld bug, but not a lot of userspace apps were using dma-buf polling\ninterfaces. Fix those, in particular this fixes KDE stalls/deadlock.(CVE-2024-43863)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix null ptr deref in dtInsertEntry\r\n\r\n[syzbot reported]\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nRIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713\n...\n[Analyze]\nIn dtInsertEntry(), when the pointer h has the same value as p, after writing\nname in UniStrncpy_to_le(), p-\u0026gt;header.flag will be cleared. This will cause the\npreviously true judgment \u0026quot;p-\u0026gt;header.flag \u0026amp; BT-LEAF\u0026quot; to change to no after writing\nthe name operation, this leads to entering an incorrect branch and accessing the\nuninitialized object ih when judging this condition for the second time.\r\n\r\n[Fix]\nAfter got the page, check freelist first, if freelist == 0 then exit dtInsert()\nand return -EINVAL.(CVE-2024-44939)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/mm: Fix pti_clone_pgtable() alignment assumption\r\n\r\nGuenter reported dodgy crashes on an i386-nosmp build using GCC-11\nthat had the form of endless traps until entry stack exhaust and then\n#DF from the stack guard.\r\n\r\nIt turned out that pti_clone_pgtable() had alignment assumptions on\nthe start address, notably it hard assumes start is PMD aligned. This\nis true on x86_64, but very much not true on i386.\r\n\r\nThese assumptions can cause the end condition to malfunction, leading\nto a \u0026apos;short\u0026apos; clone. Guess what happens when the user mapping has a\nshort copy of the entry text?\r\n\r\nUse the correct increment form for addr to avoid alignment\nassumptions.(CVE-2024-44965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hns3: fix a deadlock problem when config TC during resetting\r\n\r\nWhen config TC during the reset process, may cause a deadlock, the flow is\nas below:\n                             pf reset start\n                                 │\n                                 ▼\n                              ......\nsetup tc                         │\n    │                            ▼\n    ▼                      DOWN: napi_disable()\nnapi_disable()(skip)             │\n    │                            │\n    ▼                            ▼\n  ......                      ......\n    │                            │\n    ▼                            │\nnapi_enable()                    │\n                                 ▼\n                           UINIT: netif_napi_del()\n                                 │\n                                 ▼\n                              ......\n                                 │\n                                 ▼\n                           INIT: netif_napi_add()\n                                 │\n                                 ▼\n                              ......                 global reset start\n                                 │                      │\n                                 ▼                      ▼\n                           UP: napi_enable()(skip)    ......\n                                 │                      │\n                                 ▼                      ▼\n                              ......                 napi_disable()\r\n\r\nIn reset process, the driver will DOWN the port and then UINIT, in this\ncase, the setup tc process will UP the port before UINIT, so cause the\nproblem. Adds a DOWN process in UINIT to fix it.(CVE-2024-44995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngtp: pull network headers in gtp_dev_xmit()\r\n\r\nsyzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]\r\n\r\nWe must make sure the IPv4 or Ipv6 header is pulled in skb-\u0026gt;head\nbefore accessing fields in them.\r\n\r\nUse pskb_inet_may_pull() to fix this issue.\r\n\r\n[1]\nBUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n  ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n  gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n  gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n  __netdev_start_xmit include/linux/netdevice.h:4913 [inline]\n  netdev_start_xmit include/linux/netdevice.h:4922 [inline]\n  xmit_one net/core/dev.c:3580 [inline]\n  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596\n  __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423\n  dev_queue_xmit include/linux/netdevice.h:3105 [inline]\n  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n  packet_snd net/packet/af_packet.c:3145 [inline]\n  packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  __sys_sendto+0x685/0x830 net/socket.c:2204\n  __do_sys_sendto net/socket.c:2216 [inline]\n  __se_sys_sendto net/socket.c:2212 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:3994 [inline]\n  slab_alloc_node mm/slub.c:4037 [inline]\n  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080\n  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583\n  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674\n  alloc_skb include/linux/skbuff.h:1320 [inline]\n  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526\n  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815\n  packet_alloc_skb net/packet/af_packet.c:2994 [inline]\n  packet_snd net/packet/af_packet.c:3088 [inline]\n  packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  __sys_sendto+0x685/0x830 net/socket.c:2204\n  __do_sys_sendto net/socket.c:2216 [inline]\n  __se_sys_sendto net/socket.c:2212 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nCPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024(CVE-2024-44999)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvfs: Don\u0026apos;t evict inode under the inode lru traversing context\r\n\r\nThe inode reclaiming process(See function prune_icache_sb) collects all\nreclaimable inodes and mark them with I_FREEING flag at first, at that\ntime, other processes will be stuck if they try getting these inodes\n(See function find_inode_fast), then the reclaiming process destroy the\ninodes by function dispose_list(). Some filesystems(eg. ext4 with\nea_inode feature, ubifs with xattr) may do inode lookup in the inode\nevicting callback function, if the inode lookup is operated under the\ninode lru traversing context, deadlock problems may happen.\r\n\r\nCase 1: In function ext4_evict_inode(), the ea inode lookup could happen\n        if ea_inode feature is enabled, the lookup process will be stuck\n\tunder the evicting context like this:\r\n\r\n 1. File A has inode i_reg and an ea inode i_ea\n 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru-\u0026gt;i_ea\n 3. Then, following three processes running like this:\r\n\r\n    PA                              PB\n echo 2 \u0026gt; /proc/sys/vm/drop_caches\n  shrink_slab\n   prune_dcache_sb\n   // i_reg is added into lru, lru-\u0026gt;i_ea-\u0026gt;i_reg\n   prune_icache_sb\n    list_lru_walk_one\n     inode_lru_isolate\n      i_ea-\u0026gt;i_state |= I_FREEING // set inode state\n     inode_lru_isolate\n      __iget(i_reg)\n      spin_unlock(\u0026amp;i_reg-\u0026gt;i_lock)\n      spin_unlock(lru_lock)\n                                     rm file A\n                                      i_reg-\u0026gt;nlink = 0\n      iput(i_reg) // i_reg-\u0026gt;nlink is 0, do evict\n       ext4_evict_inode\n        ext4_xattr_delete_inode\n         ext4_xattr_inode_dec_ref_all\n          ext4_xattr_inode_iget\n           ext4_iget(i_ea-\u0026gt;i_ino)\n            iget_locked\n             find_inode_fast\n              __wait_on_freeing_inode(i_ea) ----→ AA deadlock\n    dispose_list // cannot be executed by prune_icache_sb\n     wake_up_bit(\u0026amp;i_ea-\u0026gt;i_state)\r\n\r\nCase 2: In deleted inode writing function ubifs_jnl_write_inode(), file\n        deleting process holds BASEHD\u0026apos;s wbuf-\u0026gt;io_mutex while getting the\n\txattr inode, which could race with inode reclaiming process(The\n        reclaiming process could try locking BASEHD\u0026apos;s wbuf-\u0026gt;io_mutex in\n\tinode evicting function), then an ABBA deadlock problem would\n\thappen as following:\r\n\r\n 1. File A has inode ia and a xattr(with inode ixa), regular file B has\n    inode ib and a xattr.\n 2. getfattr(A, xattr_buf) // ixa is added into lru // lru-\u0026gt;ixa\n 3. Then, following three processes running like this:\r\n\r\n        PA                PB                        PC\n                echo 2 \u0026gt; /proc/sys/vm/drop_caches\n                 shrink_slab\n                  prune_dcache_sb\n                  // ib and ia are added into lru, lru-\u0026gt;ixa-\u0026gt;ib-\u0026gt;ia\n                  prune_icache_sb\n                   list_lru_walk_one\n                    inode_lru_isolate\n                     ixa-\u0026gt;i_state |= I_FREEING // set inode state\n                    inode_lru_isolate\n                     __iget(ib)\n                     spin_unlock(\u0026amp;ib-\u0026gt;i_lock)\n                     spin_unlock(lru_lock)\n                                                   rm file B\n                                                    ib-\u0026gt;nlink = 0\n rm file A\n  iput(ia)\n   ubifs_evict_inode(ia)\n    ubifs_jnl_delete_inode(ia)\n     ubifs_jnl_write_inode(ia)\n      make_reservation(BASEHD) // Lock wbuf-\u0026gt;io_mutex\n      ubifs_iget(ixa-\u0026gt;i_ino)\n       iget_locked\n        find_inode_fast\n         __wait_on_freeing_inode(ixa)\n          |          iput(ib) // ib-\u0026gt;nlink is 0, do evict\n          |           ubifs_evict_inode\n          |            ubifs_jnl_delete_inode(ib)\n          ↓             ubifs_jnl_write_inode\n     ABBA deadlock ←-----make_reservation(BASEHD)\n                   dispose_list // cannot be executed by prune_icache_sb\n                    wake_up_bit(\u0026amp;ixa-\u0026gt;i_state)\r\n\r\nFix the possible deadlock by using new inode state flag I_LRU_ISOLATING\nto pin the inode in memory while inode_lru_isolate(\n---truncated---(CVE-2024-45003)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE\r\n\r\ncopy_fd_bitmaps(new, old, count) is expected to copy the first\ncount/BITS_PER_LONG bits from old-\u0026gt;full_fds_bits[] and fill\nthe rest with zeroes.  What it does is copying enough words\n(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.\nThat works fine, *if* all bits past the cutoff point are\nclear.  Otherwise we are risking garbage from the last word\nwe\u0026apos;d copied.\r\n\r\nFor most of the callers that is true - expand_fdtable() has\ncount equal to old-\u0026gt;max_fds, so there\u0026apos;s no open descriptors\npast count, let alone fully occupied words in -\u0026gt;open_fds[],\nwhich is what bits in -\u0026gt;full_fds_bits[] correspond to.\r\n\r\nThe other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),\nwhich is the smallest multiple of BITS_PER_LONG that covers all\nopened descriptors below max_fds.  In the common case (copying on\nfork()) max_fds is ~0U, so all opened descriptors will be below\nit and we are fine, by the same reasons why the call in expand_fdtable()\nis safe.\r\n\r\nUnfortunately, there is a case where max_fds is less than that\nand where we might, indeed, end up with junk in -\u0026gt;full_fds_bits[] -\nclose_range(from, to, CLOSE_RANGE_UNSHARE) with\n\t* descriptor table being currently shared\n\t* \u0026apos;to\u0026apos; being above the current capacity of descriptor table\n\t* \u0026apos;from\u0026apos; being just under some chunk of opened descriptors.\nIn that case we end up with observably wrong behaviour - e.g. spawn\na child with CLONE_FILES, get all descriptors in range 0..127 open,\nthen close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending\nup with descriptor #128, despite #64 being observably not open.\r\n\r\nThe minimally invasive fix would be to deal with that in dup_fd().\nIf this proves to add measurable overhead, we can go that way, but\nlet\u0026apos;s try to fix copy_fd_bitmaps() first.\r\n\r\n* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).\n* make copy_fd_bitmaps() take the bitmap size in words, rather than\nbits; it\u0026apos;s \u0026apos;count\u0026apos; argument is always a multiple of BITS_PER_LONG,\nso we are not losing any information, and that way we can use the\nsame helper for all three bitmaps - compiler will see that count\nis a multiple of BITS_PER_LONG for the large ones, so it\u0026apos;ll generate\nplain memcpy()+memset().\r\n\r\nReproducer added to tools/testing/selftests/core/close_range_test.c(CVE-2024-45025)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmmc: mmc_test: Fix NULL dereference on allocation failure\r\n\r\nIf the \u0026quot;test-\u0026gt;highmem = alloc_pages()\u0026quot; allocation fails then calling\n__free_pages(test-\u0026gt;highmem) will result in a NULL dereference.  Also\nchange the error code to -ENOMEM instead of returning success.(CVE-2024-45028)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Skip wbscl_set_scaler_filter if filter is null\r\n\r\nCallers can pass null in filter (i.e. from returned from the function\nwbscl_get_filter_coeffs_16p) and a null check is added to ensure that is\nnot the case.\r\n\r\nThis fixes 4 NULL_RETURNS issues reported by Coverity.(CVE-2024-46714)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix ucode out-of-bounds read warning\r\n\r\nClear warning that read ucode[] may out-of-bounds.(CVE-2024-46723)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: fix the Out-of-bounds read warning\r\n\r\nusing index i - 1U may beyond element index\nfor mc_data[] when i = 0.(CVE-2024-46731)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: fix qgroup reserve leaks in cow_file_range\r\n\r\nIn the buffered write path, the dirty page owns the qgroup reserve until\nit creates an ordered_extent.\r\n\r\nTherefore, any errors that occur before the ordered_extent is created\nmust free that reservation, or else the space is leaked. The fstest\ngeneric/475 exercises various IO error paths, and is able to trigger\nerrors in cow_file_range where we fail to get to allocating the ordered\nextent. Note that because we *do* clear delalloc, we are likely to\nremove the inode from the delalloc list, so the inodes/pages to not have\ninvalidate/launder called on them in the commit abort path.\r\n\r\nThis results in failures at the unmount stage of the test that look like:\r\n\r\n  BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure\n  BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure\n  BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672\n  ------------[ cut here ]------------\n  WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs]\n  Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq\n  CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W          6.10.0-rc7-gab56fde445b8 #21\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\n  RIP: 0010:close_ctree+0x222/0x4d0 [btrfs]\n  RSP: 0018:ffffb4465283be00 EFLAGS: 00010202\n  RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001\n  RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8\n  RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000\n  R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c\n  R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n  FS:  00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? close_ctree+0x222/0x4d0 [btrfs]\n   ? __warn.cold+0x8e/0xea\n   ? close_ctree+0x222/0x4d0 [btrfs]\n   ? report_bug+0xff/0x140\n   ? handle_bug+0x3b/0x70\n   ? exc_invalid_op+0x17/0x70\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? close_ctree+0x222/0x4d0 [btrfs]\n   generic_shutdown_super+0x70/0x160\n   kill_anon_super+0x11/0x40\n   btrfs_kill_super+0x11/0x20 [btrfs]\n   deactivate_locked_super+0x2e/0xa0\n   cleanup_mnt+0xb5/0x150\n   task_work_run+0x57/0x80\n   syscall_exit_to_user_mode+0x121/0x130\n   do_syscall_64+0xab/0x1a0\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n  RIP: 0033:0x7f916847a887\n  ---[ end trace 0000000000000000 ]---\n  BTRFS error (device dm-8 state EA): qgroup reserved space leaked\r\n\r\nCases 2 and 3 in the out_reserve path both pertain to this type of leak\nand must free the reserved qgroup data. Because it is already an error\npath, I opted not to handle the possible errors in\nbtrfs_free_qgroup_data.(CVE-2024-46733)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open()\r\n\r\nnull-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE)\nand parse_lease_state() return NULL.\r\n\r\nFix this by check if \u0026apos;lease_ctx_info\u0026apos; is NULL.\r\n\r\nAdditionally, remove the redundant parentheses in\nparse_durable_handle_context().(CVE-2024-46742)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSquashfs: sanity check symbolic link size\r\n\r\nSyzkiller reports a \u0026quot;KMSAN: uninit-value in pick_link\u0026quot; bug.\r\n\r\nThis is caused by an uninitialised page, which is ultimately caused\nby a corrupted symbolic link size read from disk.\r\n\r\nThe reason why the corrupted symlink size causes an uninitialised\npage is due to the following sequence of events:\r\n\r\n1. squashfs_read_inode() is called to read the symbolic\n   link from disk.  This assigns the corrupted value\n   3875536935 to inode-\u0026gt;i_size.\r\n\r\n2. Later squashfs_symlink_read_folio() is called, which assigns\n   this corrupted value to the length variable, which being a\n   signed int, overflows producing a negative number.\r\n\r\n3. The following loop that fills in the page contents checks that\n   the copied bytes is less than length, which being negative means\n   the loop is skipped, producing an uninitialised page.\r\n\r\nThis patch adds a sanity check which checks that the symbolic\nlink size is not larger than expected.\r\n\r\n--\r\n\r\nV2: fix spelling mistake.(CVE-2024-46744)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: uinput - reject requests with unreasonable number of slots\r\n\r\n\nWhen exercising uinput interface syzkaller may try setting up device\nwith a really large number of slots, which causes memory allocation\nfailure in input_mt_init_slots(). While this allocation failure is\nhandled properly and request is rejected, it results in syzkaller\nreports. Additionally, such request may put undue burden on the\nsystem which will try to free a lot of memory for a bogus request.\r\n\r\nFix it by limiting allowed number of slots to 100. This can easily\nbe extended if we see devices that can track more than 100 contacts.(CVE-2024-46745)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup\r\n\r\nreport_fixup for the Cougar 500k Gaming Keyboard was not verifying\nthat the report descriptor size was correct before accessing it(CVE-2024-46747)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don\u0026apos;t BUG_ON() when 0 reference count at btrfs_lookup_extent_info()\r\n\r\nInstead of doing a BUG_ON() handle the error by returning -EUCLEAN,\naborting the transaction and logging an error message.(CVE-2024-46751)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: replace BUG_ON() with error handling at update_ref_for_cow()\r\n\r\nInstead of a BUG_ON() just return an error, log an error message and\nabort the transaction in case we find an extent buffer belonging to the\nrelocation tree that doesn\u0026apos;t have the full backref flag set. This is\nunexpected and should never happen (save for bugs or a potential bad\nmemory).(CVE-2024-46752)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nuserfaultfd: fix checks for huge PMDs\r\n\r\nPatch series \u0026quot;userfaultfd: fix races around pmd_trans_huge() check\u0026quot;, v2.\r\n\r\nThe pmd_trans_huge() code in mfill_atomic() is wrong in three different\nways depending on kernel version:\r\n\r\n1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit\n   the right two race windows) - I\u0026apos;ve tested this in a kernel build with\n   some extra mdelay() calls. See the commit message for a description\n   of the race scenario.\n   On older kernels (before 6.5), I think the same bug can even\n   theoretically lead to accessing transhuge page contents as a page table\n   if you hit the right 5 narrow race windows (I haven\u0026apos;t tested this case).\n2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for\n   detecting PMDs that don\u0026apos;t point to page tables.\n   On older kernels (before 6.5), you\u0026apos;d just have to win a single fairly\n   wide race to hit this.\n   I\u0026apos;ve tested this on 6.1 stable by racing migration (with a mdelay()\n   patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86\n   VM, that causes a kernel oops in ptlock_ptr().\n3. On newer kernels (\u0026gt;=6.5), for shmem mappings, khugepaged is allowed\n   to yank page tables out from under us (though I haven\u0026apos;t tested that),\n   so I think the BUG_ON() checks in mfill_atomic() are just wrong.\r\n\r\nI decided to write two separate fixes for these (one fix for bugs 1+2, one\nfix for bug 3), so that the first fix can be backported to kernels\naffected by bugs 1+2.\r\n\r\n\nThis patch (of 2):\r\n\r\nThis fixes two issues.\r\n\r\nI discovered that the following race can occur:\r\n\r\n  mfill_atomic                other thread\n  ============                ============\n                              \u0026lt;zap PMD\u0026gt;\n  pmdp_get_lockless() [reads none pmd]\n  \u0026lt;bail if trans_huge\u0026gt;\n  \u0026lt;if none:\u0026gt;\n                              \u0026lt;pagefault creates transhuge zeropage\u0026gt;\n    __pte_alloc [no-op]\n                              \u0026lt;zap PMD\u0026gt;\n  \u0026lt;bail if pmd_trans_huge(*dst_pmd)\u0026gt;\n  BUG_ON(pmd_none(*dst_pmd))\r\n\r\nI have experimentally verified this in a kernel with extra mdelay() calls;\nthe BUG_ON(pmd_none(*dst_pmd)) triggers.\r\n\r\nOn kernels newer than commit 0d940a9b270b (\u0026quot;mm/pgtable: allow\npte_offset_map[_lock]() to fail\u0026quot;), this can\u0026apos;t lead to anything worse than\na BUG_ON(), since the page table access helpers are actually designed to\ndeal with page tables concurrently disappearing; but on older kernels\n(\u0026lt;=6.4), I think we could probably theoretically race past the two\nBUG_ON() checks and end up treating a hugepage as a page table.\r\n\r\nThe second issue is that, as Qi Zheng pointed out, there are other types\nof huge PMDs that pmd_trans_huge() can\u0026apos;t catch: devmap PMDs and swap PMDs\n(in particular, migration PMDs).\r\n\r\nOn \u0026lt;=6.4, this is worse than the first issue: If mfill_atomic() runs on a\nPMD that contains a migration entry (which just requires winning a single,\nfairly wide race), it will pass the PMD to pte_offset_map_lock(), which\nassumes that the PMD points to a page table.\r\n\r\nBreakage follows: First, the kernel tries to take the PTE lock (which will\ncrash or maybe worse if there is no \u0026quot;struct page\u0026quot; for the address bits in\nthe migration entry PMD - I think at least on X86 there usually is no\ncorresponding \u0026quot;struct page\u0026quot; thanks to the PTE inversion mitigation, amd64\nlooks different).\r\n\r\nIf that didn\u0026apos;t crash, the kernel would next try to write a PTE into what\nit wrongly thinks is a page table.\r\n\r\nAs part of fixing these issues, get rid of the check for pmd_trans_huge()\nbefore __pte_alloc() - that\u0026apos;s redundant, we\u0026apos;re going to have to check for\nthat after the __pte_alloc() anyway.\r\n\r\nBackport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.(CVE-2024-46787)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsch/netem: fix use after free in netem_dequeue\r\n\r\nIf netem_dequeue() enqueues packet to inner qdisc and that qdisc\nreturns __NET_XMIT_STOLEN. The packet is dropped but\nqdisc_tree_reduce_backlog() is not called to update the parent\u0026apos;s\nq.qlen, leading to the similar use-after-free as Commit\ne04991a48dbaf382 (\u0026quot;netem: fix return value if duplicate enqueue\nfails\u0026quot;)\r\n\r\nCommands to trigger KASAN UaF:\r\n\r\nip link add type dummy\nip link set lo up\nip link set dummy0 up\ntc qdisc add dev lo parent root handle 1: drr\ntc filter add dev lo parent 1: basic classid 1:1\ntc class add dev lo classid 1:1 drr\ntc qdisc add dev lo parent 1:1 handle 2: netem\ntc qdisc add dev lo parent 2: handle 3: drr\ntc filter add dev lo parent 3: basic classid 3:1 action mirred egress\nredirect dev dummy0\ntc class add dev lo classid 3:1 drr\nping -c1 -W0.01 localhost # Trigger bug\ntc class del dev lo classid 1:1\ntc class add dev lo classid 1:1 drr\nping -c1 -W0.01 localhost # UaF(CVE-2024-46800)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-230.0.0.129.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm","kernel-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm","perf-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-230.0.0.129.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-230.0.0.129.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm","kernel-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm","perf-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-230.0.0.129.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2182"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47205"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48828"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35837"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-39501"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40978"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-40980"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41017"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41098"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42104"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42119"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-42292"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43846"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43863"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44939"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44965"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44995"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44999"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45003"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45025"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45028"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46714"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46723"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46731"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46733"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46742"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46744"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46745"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46747"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46751"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46752"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46787"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46800"}],"database_specific":{"severity":"High"}}