{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
          "kernel-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
          "perf-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-64.0.0.61.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-64.0.0.61.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-64.0.0.61.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
          "kernel-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
          "perf-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-64.0.0.61.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-64.0.0.61.oe2403.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-64.0.0.61.oe2403"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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:  xhci: Handle TD clearing for multiple streams case  When multiple streams are in use, multiple TDs might be in flight when an endpoint is stopped. We need to issue a Set TR Dequeue Pointer for each, to ensure everything is reset properly and the caches cleared. Change the logic so that any N\u0026gt;1 TDs found active for different streams are deferred until after the first one is processed, calling xhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to queue another command until we are done with all of them. Also change the error/\u0026quot;should never happen\u0026quot; paths to ensure we at least clear any affected TDs, even if we can\u0026apos;t issue a command to clear the hardware cache, and complain loudly with an xhci_warn() if this ever happens.  This problem case dates back to commit e9df17eb1408 (\u0026quot;USB: xhci: Correct assumptions about number of rings per endpoint.\u0026quot;) early on in the XHCI driver\u0026apos;s life, when stream support was first added. It was then identified but not fixed nor made into a warning in commit 674f8438c121 (\u0026quot;xhci: split handling halted endpoints into two steps\u0026quot;), which added a FIXME comment for the problem case (without materially changing the behavior as far as I can tell, though the new logic made the problem more obvious).  Then later, in commit 94f339147fc3 (\u0026quot;xhci: Fix failure to give back some cached cancelled URBs.\u0026quot;), it was acknowledged again.  [Mathias: commit 94f339147fc3 (\u0026quot;xhci: Fix failure to give back some cached cancelled URBs.\u0026quot;) was a targeted regression fix to the previously mentioned patch. Users reported issues with usb stuck after unmounting/disconnecting UAS devices. This rolled back the TD clearing of multiple streams to its original state.]  Apparently the commit author was aware of the problem (yet still chose to submit it): It was still mentioned as a FIXME, an xhci_dbg() was added to log the problem condition, and the remaining issue was mentioned in the commit description. The choice of making the log type xhci_dbg() for what is, at this point, a completely unhandled and known broken condition is puzzling and unfortunate, as it guarantees that no actual users would see the log in production, thereby making it nigh undebuggable (indeed, even if you turn on DEBUG, the message doesn\u0026apos;t really hint at there being a problem at all).  It took me *months* of random xHC crashes to finally find a reliable repro and be able to do a deep dive debug session, which could all have been avoided had this unhandled, broken condition been actually reported with a warning, as it should have been as a bug intentionally left in unfixed (never mind that it shouldn\u0026apos;t have been left in at all).  \u0026gt; Another fix to solve clearing the caches of all stream rings with \u0026gt; cancelled TDs is needed, but not as urgent.  3 years after that statement and 14 years after the original bug was introduced, I think it\u0026apos;s finally time to fix it. And maybe next time let\u0026apos;s not leave bugs unfixed (that are actually worse than the original bug), and let\u0026apos;s actually get people to review kernel commits please.  Fixes xHC crashes and IOMMU faults with UAS devices when handling errors/faults. Easiest repro is to use `hdparm` to mark an early sector (e.g. 1024) on a disk as bad, then `cat /dev/sdX \u0026gt; /dev/null` in a loop. At least in the case of JMicron controllers, the read errors end up having to cancel two TDs (for two queued requests to different streams) and the one that didn\u0026apos;t get cleared properly ends up faulting the xHC entirely when it tries to access DMA pages that have since been unmapped, referred to by the stale TDs. This normally happens quickly (after two or three loops). After this fix, I left the `cat` in a loop running overnight and experienced no xHC failures, with all read errors recovered properly. Repro\u0026apos;d and tested on an Apple M1 Mac Mini (dwc3 host).  On systems without an IOMMU, this bug would instead silently corrupt freed memory, making this a ---truncated---(CVE-2024-40927)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error  Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access.  dev-\u0026gt;filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index \u0026gt; 32 to index \u0026gt;= 32 to resolve this issue.(CVE-2024-47697)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()  Since \u0026apos;__dev_queue_xmit()\u0026apos; should be called with interrupts enabled, the following backtrace:  ieee80211_do_stop()  ...  spin_lock_irqsave(\u0026amp;local-\u0026gt;queue_stop_reason_lock, flags)  ...  ieee80211_free_txskb()   ieee80211_report_used_skb()    ieee80211_report_ack_skb()     cfg80211_mgmt_tx_status_ext()      nl80211_frame_tx_status()       genlmsg_multicast_netns()        genlmsg_multicast_netns_filtered()         nlmsg_multicast_filtered()   netlink_broadcast_filtered()    do_one_broadcast()     netlink_broadcast_deliver()      __netlink_sendskb()       netlink_deliver_tap()        __netlink_deliver_tap_skb()         dev_queue_xmit()          __dev_queue_xmit() ; with IRQS disabled  ...  spin_unlock_irqrestore(\u0026amp;local-\u0026gt;queue_stop_reason_lock, flags)  issues the warning (as reported by syzbot reproducer):  WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120  Fix this by implementing a two-phase skb reclamation in \u0026apos;ieee80211_do_stop()\u0026apos;, where actual work is performed outside of a section with interrupts disabled.(CVE-2024-47713)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: don\u0026apos;t use rate mask for offchannel TX either  Like the commit ab9177d83c04 (\u0026quot;wifi: mac80211: don\u0026apos;t use rate mask for scanning\u0026quot;), ignore incorrect settings to avoid no supported rate warning reported by syzbot.  The syzbot did bisect and found cause is commit 9df66d5b9f45 (\u0026quot;cfg80211: fix default HE tx bitrate mask in 2G band\u0026quot;), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL.  As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well.  [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024(CVE-2024-47738)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check phantom_stream before it is used  dcn32_enable_phantom_stream can return null, so returned value must be checked before used.  This fixes 1 NULL_RETURNS issue reported by Coverity.(CVE-2024-49897)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags  [WHAT \u0026amp; HOW] \u0026quot;dcn20_validate_apply_pipe_split_flags\u0026quot; dereferences merge, and thus it cannot be a null pointer. Let\u0026apos;s pass a valid pointer to avoid null dereference.  This fixes 2 FORWARD_NULL issues reported by Coverity.(CVE-2024-49923)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: stmmac: Fix zero-division error when disabling tc cbs  The commit b8c43360f6e4 (\u0026quot;net: stmmac: No need to calculate speed divider when offload is disabled\u0026quot;) allows the \u0026quot;port_transmit_rate_kbps\u0026quot; to be set to a value of 0, which is then passed to the \u0026quot;div_s64\u0026quot; function when tc-cbs is disabled. This leads to a zero-division error.  When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.(CVE-2024-49977)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer  Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.(CVE-2024-49991)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: ethernet: lantiq_etop: fix memory disclosure  When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer.  In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions.  Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.(CVE-2024-49997)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()  A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could possibly return NULL pointer. NULL Pointer Dereference may be triggerred without addtional check. Add a NULL check for the returned pointer.(CVE-2024-50103)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  x86/lam: Disable ADDRESS_MASKING in most cases  Linear Address Masking (LAM) has a weakness related to transient execution as described in the SLAM paper[1]. Unless Linear Address Space Separation (LASS) is enabled this weakness may be exploitable.  Until kernel adds support for LASS[2], only allow LAM for COMPILE_TEST, or when speculation mitigations have been disabled at compile time, otherwise keep LAM disabled.  There are no processors in market that support LAM yet, so currently nobody is affected by this issue.  [1] SLAM: https://download.vusec.net/papers/slam_sp24.pdf [2] LASS: https://lore.kernel.org/lkml/20230609183632.48706-1-alexander.shishkin@linux.intel.com/  [ dhansen: update SPECULATION_MITIGATIONS -\u0026gt; CPU_MITIGATIONS ](CVE-2024-50112)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix kernel bug due to missing clearing of buffer delay flag  Syzbot reported that after nilfs2 reads a corrupted file system image and degrades to read-only, the BUG_ON check for the buffer delay flag in submit_bh_wbc() may fail, causing a kernel bug.  This is because the buffer delay flag is not cleared when clearing the buffer state flags to discard a page/folio or a buffer head. So, fix this.  This became necessary when the use of nilfs2\u0026apos;s own page clear routine was expanded.  This state inconsistency does not occur if the buffer is written normally by log writing.(CVE-2024-50116)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd: Guard against bad data for ATIF ACPI method  If a BIOS provides bad data in response to an ATIF method call this causes a NULL pointer dereference in the caller.  ``` ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642) ? exc_page_fault (arch/x86/mm/fault.c:1542) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu ```  It has been encountered on at least one system, so guard for it.  (cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)(CVE-2024-50117)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA  Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a \u0026quot;memcpy: detected field-spanning write error\u0026quot; warning:  [   13.319813] memcpy: detected field-spanning write (size 16896) of single field \u0026quot;p-\u0026gt;data\u0026quot; at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [   13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [   13.320038] Call Trace: [   13.320173]  hgsmi_update_pointer_shape [vboxvideo] [   13.320184]  vbox_cursor_atomic_update [vboxvideo]  Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept.(CVE-2024-50134)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup()  Clang static checker(scan-build) throws below warning\uff1a   |  drivers/firmware/arm_scmi/driver.c:line 2915, column 2   |        Attempt to free released memory.  When devm_add_action_or_reset() fails, scmi_debugfs_common_cleanup() will run twice which causes double free of \u0026apos;dbg-\u0026gt;name\u0026apos;.  Remove the redundant scmi_debugfs_common_cleanup() to fix this problem.(CVE-2024-50159)\r\n\r\n(CVE-2024-50194)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  maple_tree: correct tree corruption on spanning store  Patch series \u0026quot;maple_tree: correct tree corruption on spanning store\u0026quot;, v3.  There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm.  This bug seems far more likely to happen since commit f8d112a4e657 (\u0026quot;mm/mmap: avoid zeroing vma tree in mmap_region()\u0026quot;), which is the point at which reports started to be submitted concerning this bug.  We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it.  The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node.  This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption.  The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy.  The fix patch commit message goes into great detail as to how this occurs.  This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly.  Bert has kindly tested the fix and confirmed it resolved his issues.  Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve.   This patch (of 2):  There has been a subtle bug present in the maple tree implementation from its inception.  This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this.  A range may always ultimately span two leaf nodes.  In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one.  This kind of store is dubbed a \u0026apos;spanning store\u0026apos; and is implemented by mas_wr_spanning_store().  In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type.  When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas-\u0026gt;store_type as wr_spanning_store to denote this fact.  When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e.  r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write.  We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a \u0026apos;big node\u0026apos;, which is a special node which contains enough slots to contain two leaf node\u0026apos;s worth of data.  We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node().  After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e.  r_mas.offset \u0026lt;= r_mas.end).  Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree.  Consider the following tree:  Height   0                             Root Node                                  /      \\                  pivot = 0xffff /        \\ pivot = ULONG_MAX                                /           ---truncated---(CVE-2024-50200)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()  If get_clock_desc() succeeds, it calls fget() for the clockid\u0026apos;s fd, and get the clk-\u0026gt;rwsem read lock, so the error path should release the lock to make the lock balance and fput the clockid\u0026apos;s fd to make the refcount balance and release the fd related resource.  However the below commit left the error path locked behind resulting in unbalanced locking. Check timespec64_valid_strict() before get_clock_desc() to fix it, because the \u0026quot;ts\u0026quot; is not changed after that.  [pabeni@redhat.com: fixed commit message typo](CVE-2024-50210)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  spi: spi-fsl-dspi: Fix crash when not using GPIO chip select  Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used.  Fix below crash: [    4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [    4.260762] Mem abort info: [    4.263556]   ESR = 0x0000000096000004 [    4.267308]   EC = 0x25: DABT (current EL), IL = 32 bits [    4.272624]   SET = 0, FnV = 0 [    4.275681]   EA = 0, S1PTW = 0 [    4.278822]   FSC = 0x04: level 0 translation fault [    4.283704] Data abort info: [    4.286583]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [    4.292074]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [    4.297130]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [    4.302445] [0000000000000000] user address but active_mm is swapper [    4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [    4.315072] Modules linked in: [    4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [    4.328130] Hardware name: LS1046A QDS Board (DT) [    4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [    4.339794] pc : gpiod_direction_output+0x34/0x5c [    4.344505] lr : gpiod_direction_output+0x18/0x5c [    4.349208] sp : ffff80008003b8f0 [    4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [    4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [    4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [    4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [    4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [    4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [    4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [    4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [    4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [    4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [    4.423921] Call trace: [    4.426362]  gpiod_direction_output+0x34/0x5c (P) [    4.431067]  gpiod_direction_output+0x18/0x5c (L) [    4.435771]  dspi_setup+0x220/0x334(CVE-2024-50224)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend  Commit 413db06c05e7 (\u0026quot;phy: qcom-qmp-usb: clean up probe initialisation\u0026quot;) removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver.  Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend.  Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.(CVE-2024-50239)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ACPI: CPPC: Make rmw_lock a raw_spin_lock  The following BUG was triggered:  ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (\u0026amp;cpc_ptr-\u0026gt;rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62:   #0: ffffff897ef5ec98 (\u0026amp;rq-\u0026gt;__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50   #1: ffffff880154e238 (\u0026amp;sg_policy-\u0026gt;update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue:  0x0 (events) Call trace:   dump_backtrace+0xa4/0x130   show_stack+0x20/0x38   dump_stack_lvl+0x90/0xd0   dump_stack+0x18/0x28   __lock_acquire+0x480/0x1ad8   lock_acquire+0x114/0x310   _raw_spin_lock+0x50/0x70   cpc_write+0xcc/0x370   cppc_set_perf+0xa0/0x3a8   cppc_cpufreq_fast_switch+0x40/0xc0   cpufreq_driver_fast_switch+0x4c/0x218   sugov_update_shared+0x234/0x280   update_load_avg+0x6ec/0x7b8   dequeue_entities+0x108/0x830   dequeue_task_fair+0x58/0x408   __schedule+0x4f0/0x1070   schedule+0x54/0x130   worker_thread+0xc0/0x2e8   kthread+0x130/0x148   ret_from_fork+0x10/0x20  sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock.  To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it.  [ rjw: Changelog edits ](CVE-2024-50249)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  netfilter: Fix use-after-free in get_info()  ip6table_nat module unload has refcnt warning for UAF. call trace is:  WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace:  \u0026lt;TASK\u0026gt;  get_info+0x128/0x180  do_ip6t_get_ctl+0x6a/0x430  nf_getsockopt+0x46/0x80  ipv6_getsockopt+0xb9/0x100  rawv6_getsockopt+0x42/0x190  do_sock_getsockopt+0xaa/0x180  __sys_getsockopt+0x70/0xc0  __x64_sys_getsockopt+0x20/0x30  do_syscall_64+0xa2/0x1a0  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows:  cpu0          cpu1 module_exit //mod-\u0026gt;state = MODULE_STATE_GOING   ip6table_nat_exit     xt_unregister_template  kfree(t)  //removed from templ_list           getinfo()        t = xt_find_table_lock       list_for_each_entry(tmpl, \u0026amp;xt_templates[af]...)        if (strcmp(tmpl-\u0026gt;name, name))         continue;  //table not found        try_module_get       list_for_each_entry(t, \u0026amp;xt_net-\u0026gt;tables[af]...)        return t;  //not get refcnt        module_put(t-\u0026gt;me) //uaf     unregister_pernet_subsys     //remove table from xt_net list  While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table-\u0026gt;me. Check module in xt_net-\u0026gt;tables list re-traversal to fix it.(CVE-2024-50257)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fork: only invoke khugepaged, ksm hooks if no error  There is no reason to invoke these hooks early against an mm that is in an incomplete state.  The change in commit d24062914837 (\u0026quot;fork: use __mt_dup() to duplicate maple tree in dup_mmap()\u0026quot;) makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent.  Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it\u0026apos;d require a very small allocation to fail (in practice \u0026apos;too small to fail\u0026apos;) that\u0026apos;d only occur in the most dire circumstances, meaning the fork would fail or be OOM\u0026apos;d in any case.  Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn\u0026apos;t really matter all that much if, under such dire memory pressure, we fail to register an mm with these.  As a result, we follow the example of commit d2081b2bf819 (\u0026quot;mm: khugepaged: make khugepaged_enter() void function\u0026quot;) and make ksm_fork() a void function also.  We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.(CVE-2024-50263)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  USB: serial: io_edgeport: fix use after free in debug printk  The \u0026quot;dev_dbg(\u0026amp;urb-\u0026gt;dev-\u0026gt;dev, ...\u0026quot; which happens after usb_free_urb(urb) is a use after free of the \u0026quot;urb\u0026quot; pointer.  Store the \u0026quot;dev\u0026quot; pointer at the start of the function to avoid this issue.(CVE-2024-50267)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()  The \u0026quot;*cmd\u0026quot; variable can be controlled by the user via debugfs.  That means \u0026quot;new_cam\u0026quot; can be as high as 255 while the size of the uc-\u0026gt;updated[] array is UCSI_MAX_ALTMODES (30).  The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -\u0026gt; ucsi_send_command()    -\u0026gt; ucsi_send_command_common()       -\u0026gt; ucsi_run_command() // calls ucsi-\u0026gt;ops-\u0026gt;sync_control()          -\u0026gt; ucsi_ccg_sync_control()(CVE-2024-50268)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  dm cache: fix out-of-bounds access to the dirty bitset when resizing  dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access.  Reproduce steps:  1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)  dmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot; dmsetup create cdata --table \u0026quot;0 131072 linear /dev/sdc 8192\u0026quot; dmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot; dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;  2. shrink the fast device to 512 cache blocks, triggering out-of-bounds    access to the dirty bitset (offset 0x80)  dmsetup suspend cache dmsetup reload cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot; dmsetup resume cdata dmsetup resume cache  KASAN reports:    BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0   Read of size 8 at addr ffffc900000f3080 by task dmsetup/131    (...snip...)   The buggy address belongs to the virtual mapping at    [ffffc900000f3000, ffffc900000f5000) created by:    cache_ctr+0x176a/0x35f0    (...snip...)   Memory state around the buggy address:    ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8    ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   \u0026gt;ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8                      ^    ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8    ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8  Fix by making the index post-incremented.(CVE-2024-50279)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: v4l2-tpg: prevent the risk of a division by zero  As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero.  Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.(CVE-2024-50287)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: cx24116: prevent overflows on SNR calculus  as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers.  Prevent that.(CVE-2024-50290)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove  In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [    4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [    4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [    5.096577] Call trace: [    5.099099]  dma_release_channel+0x24/0x100 [    5.103235]  stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [    5.109494]  stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx]  To avoid this issue, release channel only if the pointer is valid.(CVE-2024-50292)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  security/keys: fix slab-out-of-bounds in key_task_permission  KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362  CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace:  __dump_stack lib/dump_stack.c:82 [inline]  dump_stack+0x107/0x167 lib/dump_stack.c:123  print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400  __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560  kasan_report+0x3a/0x50 mm/kasan/report.c:585  __kuid_val include/linux/uidgid.h:36 [inline]  uid_eq include/linux/uidgid.h:63 [inline]  key_task_permission+0x394/0x410 security/keys/permission.c:54  search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793  This issue was also reported by syzbot.  It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the    pattern \u0026apos;0xxxxxxxe6\u0026apos;. 2. Reboot and add the keys obtained in step 1.  The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the    slots in a node(below tag ascend_to_node), if the slot pointer is meta    and node-\u0026gt;back_pointer != NULL(it means a root), it will proceed to    descend_to_node. However, there is an exception. If node is the root,    and one of the slots points to a shortcut, it will be treated as a    keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function.    However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as    ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT    has keys with hashes that are not similar (e.g. slot 0) and it splits    NODE A without using a shortcut. When NODE A is filled with keys that    all hashes are xxe6, the keys are similar, NODE A will split with a    shortcut. Finally, it forms the tree as shown below, where slot 6 points    to a shortcut.                        NODE A               +------\u0026gt;+---+       ROOT    |       | 0 | xxe6       +---+   |       +---+  xxxx | 0 | shortcut  :   : xxe6       +---+   |       +---+  xxe6 :   :   |       |   | xxe6       +---+   |       +---+       | 6 |---+       :   : xxe6       +---+           +---+  xxe6 :   :           | f | xxe6       +---+           +---+  xxe6 | f |       +---+  4. As mentioned above, If a slot(slot 6) of the root points to a shortcut,    it may be mistakenly transferred to a key*, leading to a read    out-of-bounds read.  To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not.  [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/  [jarkko: tweaked the commit message a bit to have an appropriate closes  tag.](CVE-2024-50301)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  HID: core: zero-initialize the report buffer  Since the report buffer is used by all kinds of drivers in various ways, let\u0026apos;s zero-initialize it during allocation to make sure that it can\u0026apos;t be ever used to leak kernel memory via specially-crafted report.(CVE-2024-50302)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT  In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it\u0026apos;s valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer.  In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT).  In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop.    net/sched/sch_api.c | 2 +-  1 file changed, 1 insertion(+), 1 deletion(-)(CVE-2024-53057)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()  The scmi_dev-\u0026gt;name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev-\u0026gt;name in scmi_bus_notifier(). So move the release of scmi_dev-\u0026gt;name to scmi_device_release() to avoid slab-use-after-free.    |  BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec   |  Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1   |   |  CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1   |  Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT)   |  Call trace:   |   dump_backtrace+0x94/0x114   |   show_stack+0x18/0x24   |   dump_stack_lvl+0x48/0x60   |   print_report+0xf4/0x5b0   |   kasan_report+0xa4/0xec   |   __asan_report_load1_noabort+0x20/0x2c   |   strncmp+0xe4/0xec   |   scmi_bus_notifier+0x5c/0x54c   |   notifier_call_chain+0xb4/0x31c   |   blocking_notifier_call_chain+0x68/0x9c   |   bus_notify+0x54/0x78   |   device_del+0x1bc/0x840   |   device_unregister+0x20/0xb4   |   __scmi_device_destroy+0xac/0x280   |   scmi_device_destroy+0x94/0xd0   |   scmi_chan_setup+0x524/0x750   |   scmi_probe+0x7fc/0x1508   |   platform_probe+0xc4/0x19c   |   really_probe+0x32c/0x99c   |   __driver_probe_device+0x15c/0x3c4   |   driver_probe_device+0x5c/0x170   |   __driver_attach+0x1c8/0x440   |   bus_for_each_dev+0xf4/0x178   |   driver_attach+0x3c/0x58   |   bus_add_driver+0x234/0x4d4   |   driver_register+0xf4/0x3c0   |   __platform_driver_register+0x60/0x88   |   scmi_driver_init+0xb0/0x104   |   do_one_initcall+0xb4/0x664   |   kernel_init_freeable+0x3c8/0x894   |   kernel_init+0x24/0x1e8   |   ret_from_fork+0x10/0x20   |   |  Allocated by task 1:   |   kasan_save_stack+0x2c/0x54   |   kasan_set_track+0x2c/0x40   |   kasan_save_alloc_info+0x24/0x34   |   __kasan_kmalloc+0xa0/0xb8   |   __kmalloc_node_track_caller+0x6c/0x104   |   kstrdup+0x48/0x84   |   kstrdup_const+0x34/0x40   |   __scmi_device_create.part.0+0x8c/0x408   |   scmi_device_create+0x104/0x370   |   scmi_chan_setup+0x2a0/0x750   |   scmi_probe+0x7fc/0x1508   |   platform_probe+0xc4/0x19c   |   really_probe+0x32c/0x99c   |   __driver_probe_device+0x15c/0x3c4   |   driver_probe_device+0x5c/0x170   |   __driver_attach+0x1c8/0x440   |   bus_for_each_dev+0xf4/0x178   |   driver_attach+0x3c/0x58   |   bus_add_driver+0x234/0x4d4   |   driver_register+0xf4/0x3c0   |   __platform_driver_register+0x60/0x88   |   scmi_driver_init+0xb0/0x104   |   do_one_initcall+0xb4/0x664   |   kernel_init_freeable+0x3c8/0x894   |   kernel_init+0x24/0x1e8   |   ret_from_fork+0x10/0x20   |   |  Freed by task 1:   |   kasan_save_stack+0x2c/0x54   |   kasan_set_track+0x2c/0x40   |   kasan_save_free_info+0x38/0x5c   |   __kasan_slab_free+0xe8/0x164   |   __kmem_cache_free+0x11c/0x230   |   kfree+0x70/0x130   |   kfree_const+0x20/0x40   |   __scmi_device_destroy+0x70/0x280   |   scmi_device_destroy+0x94/0xd0   |   scmi_chan_setup+0x524/0x750   |   scmi_probe+0x7fc/0x1508   |   platform_probe+0xc4/0x19c   |   really_probe+0x32c/0x99c   |   __driver_probe_device+0x15c/0x3c4   |   driver_probe_device+0x5c/0x170   |   __driver_attach+0x1c8/0x440   |   bus_for_each_dev+0xf4/0x178   |   driver_attach+0x3c/0x58   |   bus_add_driver+0x234/0x4d4   |   driver_register+0xf4/0x3c0   |   __platform_driver_register+0x60/0x88   |   scmi_driver_init+0xb0/0x104   |   do_one_initcall+0xb4/0x664   |   kernel_init_freeable+0x3c8/0x894   |   kernel_init+0x24/0x1e8   |   ret_from_fork+0x10/0x20(CVE-2024-53068)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  platform/x86/amd/pmc: Detect when STB is not available  Loading the amd_pmc module as:      amd_pmc enable_stb=1  ...can result in the following messages in the kernel ring buffer:      amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff     ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff     WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340  Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.(CVE-2024-53072)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  virtio_net: Add hash_key_length check  Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.(CVE-2024-53082)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format  This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.(CVE-2024-53104)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  vp_vdpa: fix id_table array not null terminated error  Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.(CVE-2024-53110)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: uncache inode which has failed entering the group  Syzbot has reported the following BUG:  kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace:  \u0026lt;TASK\u0026gt;  ? __die_body+0x5f/0xb0  ? die+0x9e/0xc0  ? do_trap+0x15a/0x3a0  ? ocfs2_set_new_buffer_uptodate+0x145/0x160  ? do_error_trap+0x1dc/0x2c0  ? ocfs2_set_new_buffer_uptodate+0x145/0x160  ? __pfx_do_error_trap+0x10/0x10  ? handle_invalid_op+0x34/0x40  ? ocfs2_set_new_buffer_uptodate+0x145/0x160  ? exc_invalid_op+0x38/0x50  ? asm_exc_invalid_op+0x1a/0x20  ? ocfs2_set_new_buffer_uptodate+0x2e/0x160  ? ocfs2_set_new_buffer_uptodate+0x144/0x160  ? ocfs2_set_new_buffer_uptodate+0x145/0x160  ocfs2_group_add+0x39f/0x15a0  ? __pfx_ocfs2_group_add+0x10/0x10  ? __pfx_lock_acquire+0x10/0x10  ? mnt_get_write_access+0x68/0x2b0  ? __pfx_lock_release+0x10/0x10  ? rcu_read_lock_any_held+0xb7/0x160  ? __pfx_rcu_read_lock_any_held+0x10/0x10  ? smack_log+0x123/0x540  ? mnt_get_write_access+0x68/0x2b0  ? mnt_get_write_access+0x68/0x2b0  ? mnt_get_write_access+0x226/0x2b0  ocfs2_ioctl+0x65e/0x7d0  ? __pfx_ocfs2_ioctl+0x10/0x10  ? smack_file_ioctl+0x29e/0x3a0  ? __pfx_smack_file_ioctl+0x10/0x10  ? lockdep_hardirqs_on_prepare+0x43d/0x780  ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10  ? __pfx_ocfs2_ioctl+0x10/0x10  __se_sys_ioctl+0xfb/0x170  do_syscall_64+0xf3/0x230  entry_SYSCALL_64_after_hwframe+0x77/0x7f ...  \u0026lt;/TASK\u0026gt;  When \u0026apos;ioctl(OCFS2_IOC_GROUP_ADD, ...)\u0026apos; has failed for the particular inode in \u0026apos;ocfs2_verify_group_and_input()\u0026apos;, corresponding buffer head remains cached and subsequent call to the same \u0026apos;ioctl()\u0026apos; for the same inode issues the BUG() in \u0026apos;ocfs2_set_new_buffer_uptodate()\u0026apos; (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with \u0026apos;ocfs2_remove_from_cache()\u0026apos; on error path in \u0026apos;ocfs2_group_add()\u0026apos;.(CVE-2024-53112)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: sync_linked_regs() must preserve subreg_def  Range propagation must not affect subreg_def marks, otherwise the following example is rewritten by verifier incorrectly when BPF_F_TEST_RND_HI32 flag is set:    0: call bpf_ktime_get_ns                   call bpf_ktime_get_ns   1: r0 \u0026amp;= 0x7fffffff       after verifier   r0 \u0026amp;= 0x7fffffff   2: w1 = w0                rewrites         w1 = w0   3: if w0 \u0026lt; 10 goto +0     --------------\u0026gt;  r11 = 0x2f5674a6     (r)   4: r1 \u0026gt;\u0026gt;= 32                               r11 \u0026lt;\u0026lt;= 32           (r)   5: r0 = r1                                 r1 |= r11            (r)   6: exit;                                   if w0 \u0026lt; 0xa goto pc+0                                              r1 \u0026gt;\u0026gt;= 32                                              r0 = r1                                              exit  (or zero extension of w1 at (2) is missing for architectures that  require zero extension for upper register half).  The following happens w/o this patch: - r0 is marked as not a subreg at (0); - w1 is marked as subreg at (2); - w1 subreg_def is overridden at (3) by copy_register_state(); - w1 is read at (5) but mark_insn_zext() does not mark (2)   for zero extension, because w1 subreg_def is not set; - because of BPF_F_TEST_RND_HI32 flag verifier inserts random   value for hi32 bits of (2) (marked (r)); - this random value is read at (5).(CVE-2024-53125)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint  When using the \u0026quot;block:block_dirty_buffer\u0026quot; tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled.  This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh-\u0026gt;b_bdev-\u0026gt;bd_dev regardless of whether the buffer head has a pointer to a block_device structure.  In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \u0026quot;uptodate\u0026quot; state for each of its caller block reading functions.  However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh-\u0026gt;b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above.  Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer\u0026apos;s uptodate flag.(CVE-2024-53130)",
  "id": "OESA-2024-2537",
  "modified": "2026-08-06T11:08:01Z",
  "published": "2024-12-13T11:08:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2537"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40927"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47697"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47713"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47738"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49897"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49923"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49977"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49991"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49997"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50103"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50112"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50116"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50117"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50134"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50159"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50194"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50200"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50210"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50224"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50239"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50249"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50257"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50263"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50267"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50268"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50279"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50287"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50290"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50292"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50301"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50302"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53057"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53068"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53072"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53082"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53104"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53110"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53112"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53125"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53130"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-40927",
    "CVE-2024-47697",
    "CVE-2024-47713",
    "CVE-2024-47738",
    "CVE-2024-49897",
    "CVE-2024-49923",
    "CVE-2024-49977",
    "CVE-2024-49991",
    "CVE-2024-49997",
    "CVE-2024-50103",
    "CVE-2024-50112",
    "CVE-2024-50116",
    "CVE-2024-50117",
    "CVE-2024-50134",
    "CVE-2024-50159",
    "CVE-2024-50194",
    "CVE-2024-50200",
    "CVE-2024-50210",
    "CVE-2024-50224",
    "CVE-2024-50239",
    "CVE-2024-50249",
    "CVE-2024-50257",
    "CVE-2024-50263",
    "CVE-2024-50267",
    "CVE-2024-50268",
    "CVE-2024-50279",
    "CVE-2024-50287",
    "CVE-2024-50290",
    "CVE-2024-50292",
    "CVE-2024-50301",
    "CVE-2024-50302",
    "CVE-2024-53057",
    "CVE-2024-53068",
    "CVE-2024-53072",
    "CVE-2024-53082",
    "CVE-2024-53104",
    "CVE-2024-53110",
    "CVE-2024-53112",
    "CVE-2024-53125",
    "CVE-2024-53130"
  ]
}