{"schema_version":"1.7.2","id":"OESA-2024-2423","modified":"2024-11-15T12:21:03Z","published":"2024-11-15T12:21:03Z","upstream":["CVE-2024-46719","CVE-2024-46794","CVE-2024-46803","CVE-2024-46807","CVE-2024-47663","CVE-2024-47668","CVE-2024-47673","CVE-2024-47693","CVE-2024-47702","CVE-2024-47726","CVE-2024-49920","CVE-2024-50082","CVE-2024-50095","CVE-2024-50120","CVE-2024-50131","CVE-2024-50145","CVE-2024-50152","CVE-2024-50156","CVE-2024-50184","CVE-2024-50186"],"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\nusb: typec: ucsi: Fix null pointer dereference in trace\r\n\r\nucsi_register_altmode checks IS_ERR for the alt pointer and treats\nNULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled,\nucsi_register_displayport returns NULL which causes a NULL pointer\ndereference in trace. Rather than return NULL, call\ntypec_port_register_altmode to register DisplayPort alternate mode\nas a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.(CVE-2024-46719)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/tdx: Fix data leak in mmio_read()\r\n\r\nThe mmio_read() function makes a TDVMCALL to retrieve MMIO data for an\naddress from the VMM.\r\n\r\nSean noticed that mmio_read() unintentionally exposes the value of an\ninitialized variable (val) on the stack to the VMM.\r\n\r\nThis variable is only needed as an output value. It did not need to be\npassed to the VMM in the first place.\r\n\r\nDo not send the original value of *val to the VMM.\r\n\r\n[ dhansen: clarify what \u0026apos;val\u0026apos; is used for. ](CVE-2024-46794)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdkfd: Check debug trap enable before write dbg_ev_file\r\n\r\nIn interrupt context, write dbg_ev_file will be run by work queue. It\nwill cause write dbg_ev_file execution after debug_trap_disable, which\nwill cause NULL pointer access.\nv2: cancel work \u0026quot;debug_event_workarea\u0026quot; before set dbg_ev_file as NULL.(CVE-2024-46803)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/amdgpu: Check tbo resource pointer\r\n\r\nValidate tbo resource pointer, skip if NULL(CVE-2024-46807)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nstaging: iio: frequency: ad9834: Validate frequency parameter value\r\n\r\nIn ad9834_write_frequency() clk_get_rate() can return 0. In such case\nad9834_calc_freqreg() call will lead to division by zero. Checking\n\u0026apos;if (fout \u0026gt; (clk_freq / 2))\u0026apos; doesn\u0026apos;t protect in case of \u0026apos;fout\u0026apos; is 0.\nad9834_write_frequency() is called from ad9834_write(), where fout is\ntaken from text buffer, which can contain any value.\r\n\r\nModify parameters checking.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-47663)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc()\r\n\r\nIf we need to increase the tree depth, allocate a new node, and then\nrace with another thread that increased the tree depth before us, we\u0026apos;ll\nstill have a preallocated node that might be used later.\r\n\r\nIf we then use that node for a new non-root node, it\u0026apos;ll still have a\npointer to the old root instead of being zeroed - fix this by zeroing it\nin the cmpxchg failure path.(CVE-2024-47668)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: mvm: pause TCM when the firmware is stopped\r\n\r\nNot doing so will make us send a host command to the transport while the\nfirmware is not alive, which will trigger a WARNING.\r\n\r\nbad state = 0\nWARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]\nRIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm]\n iwl_mvm_config_scan+0x198/0x260 [iwlmvm]\n iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm]\n iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm]\n process_one_work+0x29e/0x640\n worker_thread+0x2df/0x690\n ? rescuer_thread+0x540/0x540\n kthread+0x192/0x1e0\n ? set_kthread_struct+0x90/0x90\n ret_from_fork+0x22/0x30(CVE-2024-47673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  IB/core: Fix ib_cache_setup_one error flow cleanup  When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below.  Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue.  WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff \u0026lt;0f\u0026gt; 0b 4c 8b 75 30 e9 54 ff ff ff 48 8    3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS:  00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  \u0026lt;TASK\u0026gt;  ? show_regs+0x94/0xa0  ? __warn+0x9e/0x1c0  ? gid_table_release_one+0x181/0x1a0  ? report_bug+0x1f9/0x340  ? gid_table_release_one+0x181/0x1a0  ? handle_bug+0xa2/0x110  ? exc_invalid_op+0x31/0xa0  ? asm_exc_invalid_op+0x16/0x20  ? __warn_printk+0xc7/0x180  ? __warn_printk+0xd4/0x180  ? gid_table_release_one+0x181/0x1a0  ib_device_release+0x71/0xe0  ? __pfx_ib_device_release+0x10/0x10  device_release+0x44/0xd0  kobject_put+0x135/0x3d0  put_device+0x20/0x30  rxe_net_add+0x7d/0xa0  rxe_newlink+0xd7/0x190  nldev_newlink+0x1b0/0x2a0  ? __pfx_nldev_newlink+0x10/0x10  rdma_nl_rcv_msg+0x1ad/0x2e0  rdma_nl_rcv_skb.constprop.0+0x176/0x210  netlink_unicast+0x2de/0x400  netlink_sendmsg+0x306/0x660  __sock_sendmsg+0x110/0x120  ____sys_sendmsg+0x30e/0x390  ___sys_sendmsg+0x9b/0xf0  ? kstrtouint+0x6e/0xa0  ? kstrtouint_from_user+0x7c/0xb0  ? get_pid_task+0xb0/0xd0  ? proc_fail_nth_write+0x5b/0x140  ? __fget_light+0x9a/0x200  ? preempt_count_add+0x47/0xa0  __sys_sendmsg+0x61/0xd0  do_syscall_64+0x50/0x110  entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-47693)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: Fail verification for sign-extension of packet data/data_end/data_meta  syzbot reported a kernel crash due to   commit 1f1e864b6555 (\u0026quot;bpf: Handle sign-extenstin ctx member accesses\u0026quot;). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field.  The original code looks like:         r2 = *(s32 *)(r1 + 76) /* load __sk_buff-\u0026gt;data */         r3 = *(u32 *)(r1 + 80) /* load __sk_buff-\u0026gt;data_end */         r0 = r2         r0 += 8         if r3 \u0026gt; r0 goto +1         ... Note that __sk_buff-\u0026gt;data load has 32-bit sign extension.  After verification and convert_ctx_accesses(), the final asm code looks like:         r2 = *(u64 *)(r1 +208)         r2 = (s32)r2         r3 = *(u64 *)(r1 +80)         r0 = r2         r0 += 8         if r3 \u0026gt; r0 goto pc+1         ... Note that \u0026apos;r2 = (s32)r2\u0026apos; may make the kernel __sk_buff-\u0026gt;data address invalid which may cause runtime failure.  Currently, in C code, typically we have         void *data = (void *)(long)skb-\u0026gt;data;         void *data_end = (void *)(long)skb-\u0026gt;data_end;         ... and it will generate         r2 = *(u64 *)(r1 +208)         r3 = *(u64 *)(r1 +80)         r0 = r2         r0 += 8         if r3 \u0026gt; r0 goto pc+1  If we allow sign-extension,         void *data = (void *)(long)(int)skb-\u0026gt;data;         void *data_end = (void *)(long)skb-\u0026gt;data_end;         ... the generated code looks like         r2 = *(u64 *)(r1 +208)         r2 \u0026lt;\u0026lt;= 32         r2 s\u0026gt;\u0026gt;= 32         r3 = *(u64 *)(r1 +80)         r0 = r2         r0 += 8         if r3 \u0026gt; r0 goto pc+1 and this will cause verification failure since \u0026quot;r2 \u0026lt;\u0026lt;= 32\u0026quot; is not allowed as \u0026quot;r2\u0026quot; is a packet pointer.  To fix this issue for case   r2 = *(s32 *)(r1 + 76) /* load __sk_buff-\u0026gt;data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail.    [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/(CVE-2024-47702)\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:  drm/amd/display: Check null pointers before multiple uses  [WHAT \u0026amp; HOW] Poniters, such as stream_enc and dc-\u0026gt;bw_vbios, are null checked previously in the same function, so Coverity warns \u0026quot;implies that stream_enc and dc-\u0026gt;bw_vbios might be null\u0026quot;. They are used multiple times in the subsequent code and need to be checked.  This fixes 10 FORWARD_NULL issues reported by Coverity.(CVE-2024-49920)\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:  smb: client: Handle kstrdup failures for passwords  In smb3_reconfigure(), after duplicating ctx-\u0026gt;password and ctx-\u0026gt;password2 with kstrdup(), we need to check for allocation failures.  If ses-\u0026gt;password allocation fails, return -ENOMEM. If ses-\u0026gt;password2 allocation fails, free ses-\u0026gt;password, set it to NULL, and return -ENOMEM.(CVE-2024-50120)\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:  octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx()  build_skb() returns NULL in case of a memory allocation failure so handle it inside __octep_oq_process_rx() to avoid NULL pointer dereference.  __octep_oq_process_rx() is called during NAPI polling by the driver. If skb allocation fails, keep on pulling packets out of the Rx DMA queue: we shouldn\u0026apos;t break the polling immediately and thus falsely indicate to the octep_napi_poll() that the Rx pressure is going down. As there is no associated skb in this case, don\u0026apos;t process the packets and don\u0026apos;t push them up the network stack - they are skipped.  Helper function is implemented to unmmap/flush all the fragment buffers used by the dropped packet. \u0026apos;alloc_failures\u0026apos; counter is incremented to mark the skb allocation error in driver statistics.  Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-50145)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  smb: client: fix possible double free in smb2_set_ea()  Clang static checker(scan-build) warning： fs/smb/client/smb2ops.c:1304:2: Attempt to free released memory.  1304 |         kfree(ea);       |         ^~~~~~~~~  There is a double free in such case: \u0026apos;ea is initialized to NULL\u0026apos; -\u0026gt; \u0026apos;first successful memory allocation for ea\u0026apos; -\u0026gt; \u0026apos;something failed, goto sea_exit\u0026apos; -\u0026gt; \u0026apos;first memory release for ea\u0026apos; -\u0026gt; \u0026apos;goto replay_again\u0026apos; -\u0026gt; \u0026apos;second goto sea_exit before allocate memory for ea\u0026apos; -\u0026gt; \u0026apos;second memory release for ea resulted in double free\u0026apos;.  Re-initialie \u0026apos;ea\u0026apos; to NULL near to the replay_again label, it can fix this double free problem.(CVE-2024-50152)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()  If the allocation in msm_disp_state_dump_regs() failed then `block-\u0026gt;state` can be NULL. The msm_disp_state_print_regs() function _does_ have code to try to handle it with:    if (*reg)     dump_addr = *reg;  ...but since \u0026quot;dump_addr\u0026quot; is initialized to NULL the above is actually a noop. The code then goes on to dereference `dump_addr`.  Make the function print \u0026quot;Registers not stored\u0026quot; when it sees a NULL to solve this. Since we\u0026apos;re touching the code, fix msm_disp_state_print_regs() not to pointlessly take a double-pointer and properly mark the pointer as `const`.  Patchwork: https://patchwork.freedesktop.org/patch/619657/(CVE-2024-50156)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  virtio_pmem: Check device status before requesting flush  If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang.  So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.(CVE-2024-50184)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: explicitly clear the sk pointer, when pf-\u0026gt;create fails  We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\u0026quot;net: do not leave a dangling sk pointer, when socket creation fails\u0026quot;). The problem is that commit did not fully address the problem, as some pf-\u0026gt;create implementations do not use sk_common_release in their error paths.  For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object.  While we could chase all the pf-\u0026gt;create implementations and make sure they NULL the freed sk object on error from the socket, we can\u0026apos;t guarantee future protocols will not make the same mistake.  So it is easier to just explicitly NULL the sk pointer upon return from pf-\u0026gt;create in __sock_create. We do know that pf-\u0026gt;create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.(CVE-2024-50186)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-54.0.0.57.oe2403"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-54.0.0.57.oe2403.aarch64.rpm","bpftool-debuginfo-6.6.0-54.0.0.57.oe2403.aarch64.rpm","kernel-6.6.0-54.0.0.57.oe2403.aarch64.rpm","kernel-debuginfo-6.6.0-54.0.0.57.oe2403.aarch64.rpm","kernel-debugsource-6.6.0-54.0.0.57.oe2403.aarch64.rpm","kernel-devel-6.6.0-54.0.0.57.oe2403.aarch64.rpm","kernel-headers-6.6.0-54.0.0.57.oe2403.aarch64.rpm","kernel-source-6.6.0-54.0.0.57.oe2403.aarch64.rpm","kernel-tools-6.6.0-54.0.0.57.oe2403.aarch64.rpm","kernel-tools-debuginfo-6.6.0-54.0.0.57.oe2403.aarch64.rpm","kernel-tools-devel-6.6.0-54.0.0.57.oe2403.aarch64.rpm","perf-6.6.0-54.0.0.57.oe2403.aarch64.rpm","perf-debuginfo-6.6.0-54.0.0.57.oe2403.aarch64.rpm","python3-perf-6.6.0-54.0.0.57.oe2403.aarch64.rpm","python3-perf-debuginfo-6.6.0-54.0.0.57.oe2403.aarch64.rpm"],"src":["kernel-6.6.0-54.0.0.57.oe2403.src.rpm"],"x86_64":["bpftool-6.6.0-54.0.0.57.oe2403.x86_64.rpm","bpftool-debuginfo-6.6.0-54.0.0.57.oe2403.x86_64.rpm","kernel-6.6.0-54.0.0.57.oe2403.x86_64.rpm","kernel-debuginfo-6.6.0-54.0.0.57.oe2403.x86_64.rpm","kernel-debugsource-6.6.0-54.0.0.57.oe2403.x86_64.rpm","kernel-devel-6.6.0-54.0.0.57.oe2403.x86_64.rpm","kernel-headers-6.6.0-54.0.0.57.oe2403.x86_64.rpm","kernel-source-6.6.0-54.0.0.57.oe2403.x86_64.rpm","kernel-tools-6.6.0-54.0.0.57.oe2403.x86_64.rpm","kernel-tools-debuginfo-6.6.0-54.0.0.57.oe2403.x86_64.rpm","kernel-tools-devel-6.6.0-54.0.0.57.oe2403.x86_64.rpm","perf-6.6.0-54.0.0.57.oe2403.x86_64.rpm","perf-debuginfo-6.6.0-54.0.0.57.oe2403.x86_64.rpm","python3-perf-6.6.0-54.0.0.57.oe2403.x86_64.rpm","python3-perf-debuginfo-6.6.0-54.0.0.57.oe2403.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2423"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46719"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46794"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46803"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46807"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47663"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47668"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47673"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47693"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47702"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47726"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49920"},{"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-50120"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50131"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50145"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50152"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50156"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50184"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50186"}],"database_specific":{"severity":"High"}}