{"schema_version":"1.7.2","id":"OESA-2024-2426","modified":"2024-11-15T12:21:45Z","published":"2024-11-15T12:21:45Z","upstream":["CVE-2024-46685","CVE-2024-46702","CVE-2024-46815","CVE-2024-47679","CVE-2024-47726","CVE-2024-49859","CVE-2024-49878","CVE-2024-49896","CVE-2024-49948","CVE-2024-49949","CVE-2024-49960","CVE-2024-49967","CVE-2024-49983","CVE-2024-50002","CVE-2024-50006","CVE-2024-50013","CVE-2024-50014","CVE-2024-50082","CVE-2024-50095","CVE-2024-50131","CVE-2024-50133","CVE-2024-50142","CVE-2024-50154"],"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\npinctrl: single: fix potential NULL dereference in pcs_get_function()\r\n\r\npinmux_generic_get_function() can return NULL and the pointer \u0026apos;function\u0026apos;\nwas dereferenced without checking against NULL. Add checking of pointer\n\u0026apos;function\u0026apos; in pcs_get_function().\r\n\r\nFound by code review.(CVE-2024-46685)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthunderbolt: Mark XDomain as unplugged when router is removed\r\n\r\nI noticed that when we do discrete host router NVM upgrade and it gets\nhot-removed from the PCIe side as a result of NVM firmware authentication,\nif there is another host connected with enabled paths we hang in tearing\nthem down. This is due to fact that the Thunderbolt networking driver\nalso tries to cleanup the paths and ends up blocking in\ntb_disconnect_xdomain_paths() waiting for the domain lock.\r\n\r\nHowever, at this point we already cleaned the paths in tb_stop() so\nthere is really no need for tb_disconnect_xdomain_paths() to do that\nanymore. Furthermore it already checks if the XDomain is unplugged and\nbails out early so take advantage of that and mark the XDomain as\nunplugged when we remove the parent router.(CVE-2024-46702)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check num_valid_sets before accessing reader_wm_sets[]\r\n\r\n[WHY \u0026amp; HOW]\nnum_valid_sets needs to be checked to avoid a negative index when\naccessing reader_wm_sets[num_valid_sets - 1].\r\n\r\nThis fixes an OVERRUN issue reported by Coverity.(CVE-2024-46815)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  vfs: fix race between evice_inodes() and find_inode()\u0026amp;iput()  Hi, all  Recently I noticed a bug[1] in btrfs, after digged it into and I believe it\u0026apos;a race in vfs.  Let\u0026apos;s assume there\u0026apos;s a inode (ie ino 261) with i_count 1 is called by iput(), and there\u0026apos;s a concurrent thread calling generic_shutdown_super().  cpu0:                              cpu1: iput() // i_count is 1   -\u0026gt;spin_lock(inode)   -\u0026gt;dec i_count to 0   -\u0026gt;iput_final()                    generic_shutdown_super()     -\u0026gt;__inode_add_lru()               -\u0026gt;evict_inodes()       // cause some reason[2]           -\u0026gt;if (atomic_read(inode-\u0026gt;i_count)) continue;       // return before                  // inode 261 passed the above check       // list_lru_add_obj()             // and then schedule out    -\u0026gt;spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set  btrfs_iget()   // after some function calls   -\u0026gt;find_inode()     // found the above inode 261     -\u0026gt;spin_lock(inode)    // check I_FREEING|I_WILL_FREE    // and passed       -\u0026gt;__iget()     -\u0026gt;spin_unlock(inode)                // schedule back                                         -\u0026gt;spin_lock(inode)                                         // check (I_NEW|I_FREEING|I_WILL_FREE) flags,                                         // passed and set I_FREEING iput()                                  -\u0026gt;spin_unlock(inode)   -\u0026gt;spin_lock(inode)     -\u0026gt;evict()   // dec i_count to 0   -\u0026gt;iput_final()     -\u0026gt;spin_unlock()     -\u0026gt;evict()  Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode-\u0026gt;i_state \u0026amp; I_CLEAR) statement both within clear_inode() and iput().  To fix the bug, recheck the inode-\u0026gt;i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced.  If there is any misunderstanding, please let me know, thanks.  [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.(CVE-2024-47679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to wait dio completion  It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.(CVE-2024-47726)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to check atomic_file in f2fs ioctl interfaces  Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.(CVE-2024-49859)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  resource: fix region_intersects() vs add_memory_driver_managed()  On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows.  490000000-50fffffff : CXL Window 0   490000000-50fffffff : region0     490000000-50fffffff : dax0.0       490000000-50fffffff : System RAM (kmem)  Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \u0026quot;System RAM (kmem)\u0026quot; a descendant of \u0026quot;CXL Window X\u0026quot;.  This confuses region_intersects(), which expects all \u0026quot;System RAM\u0026quot; resources to be at the top level of iomem_resource.  This can lead to bugs.  For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem,   $ dd if=data of=/dev/mem bs=$((1 \u0026lt;\u0026lt; 10)) seek=$((0x490000000 \u0026gt;\u0026gt; 10)) count=1  dd: error writing \u0026apos;/dev/mem\u0026apos;: Bad address  1+0 records in  0+0 records out  0 bytes copied, 0.0283507 s, 0.0 kB/s  the command fails as expected.  However, the error code is wrong.  It should be \u0026quot;Operation not permitted\u0026quot; instead of \u0026quot;Bad address\u0026quot;.  More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly.  Although the accessing is prevented later because ioremap() isn\u0026apos;t allowed to map system RAM, it is a potential security issue.  During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM.   ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff  WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d  Call Trace:   memremap+0xcb/0x184   xlate_dev_mem_ptr+0x25/0x2f   write_mem+0x94/0xfb   vfs_write+0x128/0x26d   ksys_write+0xac/0xfe   do_syscall_64+0x9a/0xfd   entry_SYSCALL_64_after_hwframe+0x4b/0x53  The details of command execution process are as follows.  In the above resource tree, \u0026quot;System RAM\u0026quot; is a descendant of \u0026quot;CXL Window 0\u0026quot; instead of a top level resource.  So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources.  Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly.  Fortunately, ioremap() doesn\u0026apos;t allow to map System RAM and reject the access.  So, region_intersects() needs to be fixed to work correctly with the resource tree with \u0026quot;System RAM\u0026quot; not at top level as above.  To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources.  So, we will not miss any matched resources in resource tree anymore.  In the new implementation, an example resource tree  |------------- \u0026quot;CXL Window 0\u0026quot; ------------| |-- \u0026quot;System RAM\u0026quot; --|  will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ),  |-- \u0026quot;System RAM\u0026quot; --||-- \u0026quot;CXL Window 0a\u0026quot; --|  Where \u0026quot;CXL Window 0a\u0026quot; is part of the original \u0026quot;CXL Window 0\u0026quot; that isn\u0026apos;t covered by \u0026quot;System RAM\u0026quot;.(CVE-2024-49878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check stream before comparing them  [WHAT \u0026amp; HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them.  This fixes 1 FORWARD_NULL issue reported by Coverity.(CVE-2024-49896)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: add more sanity checks to qdisc_pkt_len_init()  One path takes care of SKB_GSO_DODGY, assuming skb-\u0026gt;len is bigger than hdr_len.  virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes.  It is possible for an user to provide a malicious \u0026apos;GSO\u0026apos; packet, total length of 80 bytes.  - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8  virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size.  We need to make detect this case to not underflow qdisc_skb_cb(skb)-\u0026gt;pkt_len.(CVE-2024-49948)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: avoid potential underflow in qdisc_pkt_len_init() with UFO  After commit 7c6d2ecbda83 (\u0026quot;net: be more gentle about silly gso requests coming from user\u0026quot;) virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet.  Then commit cf9acc90c80ec (\u0026quot;net: virtio_net_hdr_to_skb: count transport header in UFO\u0026quot;) while fixing one issue, allowed user space to cook a GSO packet with the following characteristic :  IPv4 SKB_GSO_UDP, gso_size=3, skb-\u0026gt;len = 28.  When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb-\u0026gt;len  Then the following sets gso_segs to 0 :  gso_segs = DIV_ROUND_UP(skb-\u0026gt;len - hdr_len,                         shinfo-\u0026gt;gso_size);  Then later we set qdisc_skb_cb(skb)-\u0026gt;pkt_len to back to zero :/  qdisc_skb_cb(skb)-\u0026gt;pkt_len += (gso_segs - 1) * hdr_len;  This leads to the following crash in fq_codel [1]  qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel.  This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug.  [1] [   70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [   70.724561] #PF: supervisor read access in kernel mode [   70.724561] #PF: error_code(0x0000) - not-present page [   70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [   70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [   70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [   70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [   70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 \u0026lt;49\u0026gt; 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ========    0: 24 08                 and    $0x8,%al    2: 49 c1 e1 06           shl    $0x6,%r9    6: 44 89 7c 24 18        mov    %r15d,0x18(%rsp)    b: 45 31 ed              xor    %r13d,%r13d    e: 45 31 c0              xor    %r8d,%r8d   11: 31 ff                 xor    %edi,%edi   13: 89 44 24 14           mov    %eax,0x14(%rsp)   17: 4c 03 8b 90 01 00 00  add    0x190(%rbx),%r9   1e: eb 04                 jmp    0x24   20: 39 ca                 cmp    %ecx,%edx   22: 73 37                 jae    0x5b   24: 4d 8b 39              mov    (%r9),%r15   27: 83 c7 01              add    $0x1,%edi   2a:* 49 8b 17              mov    (%r15),%rdx  \u0026lt;-- trapping instruction   2d: 49 89 11              mov    %rdx,(%r9)   30: 41 8b 57 28           mov    0x28(%r15),%edx   34: 45 8b 5f 34           mov    0x34(%r15),%r11d   38: 49 c7 07 00 00 00 00  movq   $0x0,(%r15)   3f: 49                    rex.WB  Code starting with the faulting instruction ===========================================    0: 49 8b 17              mov    (%r15),%rdx    3: 49 89 11              mov    %rdx,(%r9)    6: 41 8b 57 28           mov    0x28(%r15),%edx    a: 45 8b 5f 34           mov    0x34(%r15),%r11d    e: 49 c7 07 00 00 00 00  movq   $0x0,(%r15)   15: 49                    rex.WB [   70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [   70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [   70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [   70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [   70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [   70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [   70.724561] FS:  000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [   70.724561] CS:  0010 DS: 0000 ES: 0000 C ---truncated---(CVE-2024-49949)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix timer use-after-free on failed mount  Syzbot has found an ODEBUG bug in ext4_fill_super  The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi).  When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called.  Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.(CVE-2024-49960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: no need to continue when the number of entries is 1(CVE-2024-49967)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free  When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the \u0026apos;ppath\u0026apos; is updated but it is the \u0026apos;path\u0026apos; that is freed, thus potentially triggering a double-free in the following process:  ext4_ext_replay_update_ex   ppath = path   ext4_force_split_extent_at(\u0026amp;ppath)     ext4_split_extent_at       ext4_ext_insert_extent         ext4_ext_create_new_leaf           ext4_ext_grow_indepth             ext4_find_extent               if (depth \u0026gt; path[0].p_maxdepth)                 kfree(path)                 ---\u0026gt; path First freed                 *orig_path = path = NULL    ---\u0026gt; null ppath   kfree(path)                               ---\u0026gt; path double-free !!!  So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.(CVE-2024-49983)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  static_call: Handle module init failure correctly in static_call_del_module()  Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain.  If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries.  This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod.  The problem is that key::mods is not a individual struct member of struct static_call_key, it\u0026apos;s part of a union to save space:          union {                 /* bit 0: 0 = mods, 1 = sites */                 unsigned long type;                 struct static_call_mod *mods;                 struct static_call_site *sites;  };  key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set.  As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus.  Cure it by checking whether the key has a sites or a mods pointer.  If it\u0026apos;s a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit.  If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing.  A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can\u0026apos;t match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.(CVE-2024-50002)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix i_data_sem unlock order in ext4_ind_migrate()  Fuzzing reports a possible deadlock in jbd2_log_wait_commit.  This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call.  This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously.  Found by Linux Verification Center (linuxtesting.org) with syzkaller.  Rule: add(CVE-2024-50006)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  exfat: fix memory leak in exfat_load_bitmap()  If the first directory entry in the root directory is not a bitmap directory entry, \u0026apos;bh\u0026apos; will not be released and reassigned, which will cause a memory leak.(CVE-2024-50013)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix access to uninitialised lock in fc replay path  The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled:  INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn\u0026apos;t initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace:  \u0026lt;TASK\u0026gt;  dump_stack_lvl+0x66/0x90  register_lock_class+0x759/0x7d0  __lock_acquire+0x85/0x2630  ? __find_get_block+0xb4/0x380  lock_acquire+0xd1/0x2d0  ? __ext4_journal_get_write_access+0xd5/0x160  _raw_spin_lock+0x33/0x40  ? __ext4_journal_get_write_access+0xd5/0x160  __ext4_journal_get_write_access+0xd5/0x160  ext4_reserve_inode_write+0x61/0xb0  __ext4_mark_inode_dirty+0x79/0x270  ? ext4_ext_replay_set_iblocks+0x2f8/0x450  ext4_ext_replay_set_iblocks+0x330/0x450  ext4_fc_replay+0x14c8/0x1540  ? jread+0x88/0x2e0  ? rcu_is_watching+0x11/0x40  do_one_pass+0x447/0xd00  jbd2_journal_recover+0x139/0x1b0  jbd2_journal_load+0x96/0x390  ext4_load_and_init_journal+0x253/0xd40  ext4_fill_super+0x2cc6/0x3180 ...  In the replay path there\u0026apos;s an attempt to lock sbi-\u0026gt;s_bdev_wb_lock in function ext4_check_bdev_write_error().  Unfortunately, at this point this spinlock has not been initialized yet.  Moving it\u0026apos;s initialization to an earlier point in __ext4_fill_super() fixes this splat.(CVE-2024-50014)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race  We\u0026apos;re seeing crashes from rq_qos_wake_function that look like this:    BUG: unable to handle page fault for address: ffffafe180a40084   #PF: supervisor write access in kernel mode   #PF: error_code(0x0002) - not-present page   PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0   Oops: Oops: 0002 [#1] PREEMPT SMP PTI   CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014   RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40   Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 \u0026lt;f0\u0026gt; 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00   RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046   RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011   RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084   RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011   R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002   R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003   FS:  0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400   PKRU: 55555554   Call Trace:    \u0026lt;IRQ\u0026gt;    try_to_wake_up+0x5a/0x6a0    rq_qos_wake_function+0x71/0x80    __wake_up_common+0x75/0xa0    __wake_up+0x36/0x60    scale_up.part.0+0x50/0x110    wb_timer_fn+0x227/0x450    ...  So rq_qos_wake_function() calls wake_up_process(data-\u0026gt;task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(\u0026amp;p-\u0026gt;pi_lock).  p comes from data-\u0026gt;task, and data comes from the waitqueue entry, which is stored on the waiter\u0026apos;s stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data-\u0026gt;task. Meanwhile, the waker was passing the clobbered garbage in data-\u0026gt;task to wake_up_process(), leading to the crash.  What\u0026apos;s happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this:  rq_qos_wait()                           rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive()                                         data-\u0026gt;got_token = true;                                         list_del_init(\u0026amp;curr-\u0026gt;entry); if (data.got_token)         break; finish_wait(\u0026amp;rqw-\u0026gt;wait, \u0026amp;data.wq);   ^- returns immediately because      list_empty_careful(\u0026amp;wq_entry-\u0026gt;entry)      is true ... return, go do something else ...                                         wake_up_process(data-\u0026gt;task)                                           (NO LONGER VALID!)-^  Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue.  The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order.  Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().(CVE-2024-50082)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/mad: Improve handling of timed out WRs of mad agent  Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler.  This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes  Trace: -----  BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767]  CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE      -------  ---  5.14.0-427.13.1.el9_4.x86_64 #1  Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019  Workqueue: ib_mad1 timeout_sends [ib_core]  RIP: 0010:__do_softirq+0x78/0x2ac  RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246  RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f  RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b  RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000  R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000  R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040  FS:  0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  PKRU: 55555554  Call Trace:   \u0026lt;IRQ\u0026gt;   ? show_trace_log_lvl+0x1c4/0x2df   ? show_trace_log_lvl+0x1c4/0x2df   ? __irq_exit_rcu+0xa1/0xc0   ? watchdog_timer_fn+0x1b2/0x210   ? __pfx_watchdog_timer_fn+0x10/0x10   ? __hrtimer_run_queues+0x127/0x2c0   ? hrtimer_interrupt+0xfc/0x210   ? __sysvec_apic_timer_interrupt+0x5c/0x110   ? sysvec_apic_timer_interrupt+0x37/0x90   ? asm_sysvec_apic_timer_interrupt+0x16/0x20   ? __do_softirq+0x78/0x2ac   ? __do_softirq+0x60/0x2ac   __irq_exit_rcu+0xa1/0xc0   sysvec_call_function_single+0x72/0x90   \u0026lt;/IRQ\u0026gt;   \u0026lt;TASK\u0026gt;   asm_sysvec_call_function_single+0x16/0x20  RIP: 0010:_raw_spin_unlock_irq+0x14/0x30  RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247  RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800  RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c  RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000  R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538  R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c   cm_process_send_error+0x122/0x1d0 [ib_cm]   timeout_sends+0x1dd/0x270 [ib_core]   process_one_work+0x1e2/0x3b0   ? __pfx_worker_thread+0x10/0x10   worker_thread+0x50/0x3a0   ? __pfx_worker_thread+0x10/0x10   kthread+0xdd/0x100   ? __pfx_kthread+0x10/0x10   ret_from_fork+0x29/0x50   \u0026lt;/TASK\u0026gt;  Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs(CVE-2024-50095)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tracing: Consider the NULL character when validating the event length  strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character.  This commit checks this condition and returns failure for it.(CVE-2024-50131)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  LoongArch: Don\u0026apos;t crash in stack_top() for tasks without vDSO  Not all tasks have a vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL vdso pointer and crash.  This can for example happen when using kunit:   [\u0026lt;9000000000203874\u0026gt;] stack_top+0x58/0xa8  [\u0026lt;90000000002956cc\u0026gt;] arch_pick_mmap_layout+0x164/0x220  [\u0026lt;90000000003c284c\u0026gt;] kunit_vm_mmap_init+0x108/0x12c  [\u0026lt;90000000003c1fbc\u0026gt;] __kunit_add_resource+0x38/0x8c  [\u0026lt;90000000003c2704\u0026gt;] kunit_vm_mmap+0x88/0xc8  [\u0026lt;9000000000410b14\u0026gt;] usercopy_test_init+0xbc/0x25c  [\u0026lt;90000000003c1db4\u0026gt;] kunit_try_run_case+0x5c/0x184  [\u0026lt;90000000003c3d54\u0026gt;] kunit_generic_run_threadfn_adapter+0x24/0x48  [\u0026lt;900000000022e4bc\u0026gt;] kthread+0xc8/0xd4  [\u0026lt;9000000000200ce8\u0026gt;] ret_from_kernel_thread+0xc/0xa4(CVE-2024-50133)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  xfrm: validate new SA\u0026apos;s prefixlen using SA family when sel.family is unset  This expands the validation introduced in commit 07bf7908950a (\u0026quot;xfrm: Validate address prefix lengths in the xfrm selector.\u0026quot;)  syzbot created an SA with     usersa.sel.family = AF_UNSPEC     usersa.sel.prefixlen_s = 128     usersa.family = AF_INET  Because of the AF_UNSPEC selector, verify_newsa_info doesn\u0026apos;t put limits on prefixlen_{s,d}. But then copy_from_user_state sets x-\u0026gt;sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that\u0026apos;s how prefixlen is going to be used later on.(CVE-2024-50142)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tcp/dccp: Don\u0026apos;t use timer_pending() in reqsk_queue_unlink().  Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().    \u0026quot;\u0026quot;\u0026quot;   We are seeing a use-after-free from a bpf prog attached to   trace_tcp_retransmit_synack. The program passes the req-\u0026gt;sk to the   bpf_sk_storage_get_tracing kernel helper which does check for null   before using it.   \u0026quot;\u0026quot;\u0026quot;  The commit 83fccfc3940c (\u0026quot;inet: fix potential deadlock in reqsk_queue_unlink()\u0026quot;) added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window.  Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer-\u0026gt;entry.pprev and marks it as not pending.  If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires.  The reported UAF could happen if req-\u0026gt;sk is close()d earlier than the timer expiration, which is 63s by default.  The scenario would be    1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),      but del_timer_sync() is missed    2. reqsk timer is executed and scheduled again    3. req-\u0026gt;sk is accept()ed and reqsk_put() decrements rsk_refcnt, but      reqsk timer still has another one, and inet_csk_accept() does not      clear req-\u0026gt;sk for non-TFO sockets    4. sk is close()d    5. reqsk timer is executed again, and BPF touches req-\u0026gt;sk  Let\u0026apos;s not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop().  Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1]  [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0  Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb  kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6  allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb  freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb(CVE-2024-50154)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-136.101.0.182.oe2203sp1"}]}],"ecosystem_specific":{"aarch64":["kernel-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm","kernel-debuginfo-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm","kernel-debugsource-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm","kernel-devel-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm","kernel-headers-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm","kernel-source-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm","kernel-tools-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm","kernel-tools-debuginfo-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm","kernel-tools-devel-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm","perf-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm","perf-debuginfo-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm","python3-perf-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm","python3-perf-debuginfo-5.10.0-136.101.0.182.oe2203sp1.aarch64.rpm"],"src":["kernel-5.10.0-136.101.0.182.oe2203sp1.src.rpm"],"x86_64":["kernel-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm","kernel-debuginfo-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm","kernel-debugsource-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm","kernel-devel-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm","kernel-headers-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm","kernel-source-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm","kernel-tools-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm","kernel-tools-debuginfo-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm","kernel-tools-devel-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm","perf-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm","perf-debuginfo-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm","python3-perf-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm","python3-perf-debuginfo-5.10.0-136.101.0.182.oe2203sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2426"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46685"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46702"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46815"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47679"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47726"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49859"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49878"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49896"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49948"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49949"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49960"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49967"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49983"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50002"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50006"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50013"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50014"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50082"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50095"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50131"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50133"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50142"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50154"}],"database_specific":{"severity":"High"}}