deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-49335
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu/cs: make commands with 0 chunks illegal behaviour.

Submitting a cs with 0 chunks, causes an oops later, found trying
to execute the wrong userspace driver.

MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo

[[PII_REDACTED]84] BUG: kernel NULL pointer dereference, address:[PII_REDACTED]0001d8
[[PII_REDACTED]88] #PF: supervisor read access in kernel mode
[[PII_REDACTED]89] #PF: error_code(0x0000) - not-present page
[[PII_REDACTED]91] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0
[[PII_REDACTED]95] Oops: 0000 [#1] SMP NOPTI
[[PII_REDACTED]97] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P           O      5.10.81 #1-NixOS
[[PII_REDACTED]99] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015
[[PII_REDACTED]72] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu]
[[PII_REDACTED]74] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10
[[PII_REDACTED]76] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246
[[PII_REDACTED]77] RAX: [PII_REDACTED] RBX: [PII_REDACTED] RCX: [PII_REDACTED]
[[PII_REDACTED]78] RDX: [PII_REDACTED] RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68
[[PII_REDACTED]79] RBP: ffff[PII_REDACTED]10 R08: [PII_REDACTED] R09: ffffb47c0e81be38
[[PII_REDACTED]81] R10: ffff[PII_REDACTED]10 R11: ffff[PII_REDACTED]00 R12: ffffb47c0e81bc40
[[PII_REDACTED]82] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28
[[PII_REDACTED]83] FS:  00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:[PII_REDACTED]
[[PII_REDACTED]84] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[[PII_REDACTED]86] CR2:[PII_REDACTED]0001d8 CR3:[PII_REDACTED]e46000 CR4:[PII_REDACTED]0406e0
[[PII_REDACTED]87] Call Trace:
[[PII_REDACTED]22]  ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]
[[PII_REDACTED]32]  drm_ioctl_kernel+0xaa/0xf0 [drm]
[[PII_REDACTED]38]  drm_ioctl+0x201/0x3b0 [drm]
[[PII_REDACTED]69]  ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu]
[[PII_REDACTED]72]  ? selinux_file_ioctl+0x135/0x230
[[PII_REDACTED]99]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[[PII_REDACTED]03]  __x64_sys_ioctl+0x83/0xb0
[[PII_REDACTED]06]  do_syscall_64+0x33/0x40
[[PII_REDACTED]09]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/15c3bcc9b5349d40207e5f8d4d799b8b4b7d13b8; https://git.kernel.org/stable/c/20b947e5a3c74c5084d661c097517a554989d462; https://git.kernel.org/stable/c/31ab27b14daaa75541a415c6794d6f3567fea44a
CVE: CVE-2022-49336
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/etnaviv: check for reaped mapping in etnaviv_iommu_unmap_gem

When the mapping is already reaped the unmap must be a no-op, as we
would otherwise try to remove the mapping twice, corrupting the involved
data structures.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/03bd455a79f69d97fee3e3b212ab754442f10e5c; https://git.kernel.org/stable/c/19323b3671a85788569d15685c8f83a05ec48cbb; https://git.kernel.org/stable/c/436cff507f2a41230baacc3e2ef1d3b2d2653f40
CVE: CVE-2022-49339
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ipv6: unexport __init-annotated seg6_hmac_init()

EXPORT_SYMBOL and __init is a bad combination because the .init.text
section is freed up after the initialization. Hence, modules cannot
use symbols annotated __init. The access to a freed symbol may end up
with kernel panic.

modpost used to detect it, but it has been broken for a decade.

Recently, I fixed modpost so it started to warn it again, then this
showed up in linux-next builds.

There are two ways to fix it:

  - Remove __init
  - Remove EXPORT_SYMBOL

I chose the latter for this case because the caller (net/ipv6/seg6.c)
and the callee (net/ipv6/seg6_hmac.c) belong to the same module.
It seems an internal function call in ipv6.ko.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1084716f76c8045eadf92a9d9a62641f3c8d8c90; https://git.kernel.org/stable/c/317260b3eb6384a05a8af212308fa50f3b2e8290; https://git.kernel.org/stable/c/3e6de5037148c5a93a436b1e8d2edad3dac11755
CVE: CVE-2022-49340
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ip_gre: test csum_start instead of transport header

GRE with TUNNEL_CSUM will apply local checksum offload on
CHECKSUM_PARTIAL packets.

ipgre_xmit must validate csum_start after an optional skb_pull,
else lco_csum may trigger an overflow. The original check was

	if (csum && skb_checksum_start(skb) < skb->data)
		return -EINVAL;

This had false positives when skb_checksum_start is undefined:
when ip_summed is not CHECKSUM_PARTIAL. A discussed refinement
was straightforward

	if (csum && skb->ip_summed == CHECKSUM_PARTIAL &&
	    skb_checksum_start(skb) < skb->data)
		return -EINVAL;

But was eventually revised more thoroughly:
- restrict the check to the only branch where needed, in an
  uncommon GRE path that uses header_ops and calls skb_pull.
- test skb_transport_header, which is set along with csum_start
  in skb_partial_csum_set in the normal header_ops datapath.

Turns out skbs can arrive in this branch without the transport
header set, e.g., through BPF redirection.

Revise the check back to check csum_start directly, and only if
CHECKSUM_PARTIAL. Do leave the check in the updated location.
Check field regardless of whether TUNNEL_CSUM is configured.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0c92d813c7c9ca2212ecd879232e7d87362fce98; https://git.kernel.org/stable/c/0ffa[PII_REDACTED]33af5f37a38c212326d98ebe8c; https://git.kernel.org/stable/c/3d08bc3a5d9b2106f5c8bcf1adb73147824aa006
CVE: CVE-2022-49342
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ethernet: bgmac: Fix refcount leak in bcma_mdio_mii_register

of_get_child_by_name() returns a node pointer with refcount
incremented, we should use of_node_put() on it when not need anymore.
Add missing of_node_put() to avoid refcount leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/7fb1fe7d9a167205413f1de8db9f7d0f82c78286; https://git.kernel.org/stable/c/b51996e35bbfcc7a27d94dfeed5cc2429b2c0df4; https://git.kernel.org/stable/c/b8d91399775c55162073bb2aca061ec42e3d4bc1
CVE: CVE-2022-49343
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: avoid cycles in directory h-tree

A maliciously corrupted filesystem can contain cycles in the h-tree
stored inside a directory. That can easily lead to the kernel corrupting
tree nodes that were already verified under its hands while doing a node
split and consequently accessing unallocated memory. Fix the problem by
verifying traversed block numbers are unique.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/24b8206fec1db21d7e82f21f0b2ff5e5672cf5b3; https://git.kernel.org/stable/c/3a3ce941645407cd0b0b7f01ad9e2ea3770f46cc; https://git.kernel.org/stable/c/3ba733f879c2a[PII_REDACTED]7e41edeefbc0d92b2
CVE: CVE-2022-49344
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

af_unix: Fix a data-race in unix_dgram_peer_wake_me().

unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'s
lock held and check if its receive queue is full.  Here we need to
use unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise
KCSAN will report a data-race.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362, CWE-362
References: https://git.kernel.org/stable/c/556720013c36c193d9cbfb06e7b33e51f0c39fbf; https://git.kernel.org/stable/c/662a80946ce13633ae90a55379f1346c10f0c432; https://git.kernel.org/stable/c/71e8bfc7f838cabc60cba24e09ca84c4f8321ab2
CVE: CVE-2022-49345
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: xfrm: unexport __init-annotated xfrm4_protocol_init()

EXPORT_SYMBOL and __init is a bad combination because the .init.text
section is freed up after the initialization. Hence, modules cannot
use symbols annotated __init. The access to a freed symbol may end up
with kernel panic.

modpost used to detect it, but it has been broken for a decade.

Recently, I fixed modpost so it started to warn it again, then this
showed up in linux-next builds.

There are two ways to fix it:

  - Remove __init
  - Remove EXPORT_SYMBOL

I chose the latter for this case because the only in-tree call-site,
net/ipv4/xfrm4_policy.c is never compiled as modular.
(CONFIG_XFRM is boolean)
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2b253fbc9f7b5db18d716436bdcf8ecef09fd63d; https://git.kernel.org/stable/c/31f3c6a4dcd3260a386e62cef2d5b36e902600a1; https://git.kernel.org/stable/c/4a388f08d8784af48f352193d2b72aaf167a57a1
CVE: CVE-2022-49346
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: dsa: lantiq_gswip: Fix refcount leak in gswip_gphy_fw_list

Every iteration of for_each_available_child_of_node() decrements
the reference count of the previous node.
when breaking early from a for_each_available_child_of_node() loop,
we need to explicitly call of_node_put() on the gphy_fw_np.
Add missing of_node_put() to avoid refcount leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0737e018a05e2aa352828c52bdeed3b02cff2930; https://git.kernel.org/stable/c/2e007ac6fa7c9c94ad84da075c5c504afad690a0; https://git.kernel.org/stable/c/32cd78c5610f02a929f63cac985e73692d05f33e
CVE: CVE-2022-49347
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix bug_on in ext4_writepages

we got issue as follows:
EXT4-fs error (device loop0): ext4_mb_generate_buddy:1141: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free cls
------------[ cut here ]------------
kernel BUG at fs/ext4/inode.c:2708!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 2 PID: 2147 Comm: rep Not tainted 5.18.0-rc2-next-20220413+ #155
RIP: 0010:ext4_writepages+0x1977/0x1c10
RSP: 0018:ffff88811d3e7880 EFLAGS: 00010246
RAX: [PII_REDACTED] RBX: [PII_REDACTED] RCX: ffff88811c098000
RDX: [PII_REDACTED] RSI: ffff88811c098000 RDI: [PII_REDACTED]
RBP: ffff888128140f50 R08: ffffffffb1ff6387 R09: [PII_REDACTED]
R10: [PII_REDACTED] R11: ffffed10250281ea R12: [PII_REDACTED]
R13:[PII_REDACTED]0000a4 R14: ffff88811d3e7bb8 R15: ffff[PII_REDACTED]28
FS:  00007f443aed9740(0000) GS:ffff8883aef00000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: [PII_REDACTED] CR3: 000000011c2a4000 CR4:[PII_REDACTED]0006e0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 <TASK>
 do_writepages+0x130/0x3a0
 filemap_fdatawrite_wbc+0x83/0xa0
 filemap_flush+0xab/0xe0
 ext4_alloc_da_blocks+0x51/0x120
 __ext4_ioctl+0x1534/0x3210
 __x64_sys_ioctl+0x12c/0x170
 do_syscall_64+0x3b/0x90

It may happen as follows:
1. write inline_data inode
vfs_write
  new_sync_write
    ext4_file_write_iter
      ext4_buffered_write_iter
        generic_perform_write
          ext4_da_write_begin
            ext4_da_write_inline_data_begin -> If inline data size too
            small will allocate block to write, then mapping will has
            dirty page
                ext4_da_convert_inline_data_to_extent ->clear EXT4_STATE_MAY_INLINE_DATA
2. fallocate
do_vfs_ioctl
  ioctl_preallocate
    vfs_fallocate
      ext4_fallocate
        ext4_convert_inline_data
          ext4_convert_inline_data_nolock
            ext4_map_blocks -> fail will goto restore data
            ext4_restore_inline_data
              ext4_create_inline_data
              ext4_write_inline_data
              ext4_set_inode_state -> set inode EXT4_STATE_MAY_INLINE_DATA
3. writepages
__ext4_ioctl
  ext4_alloc_da_blocks
    filemap_flush
      filemap_fdatawrite_wbc
        do_writepages
          ext4_writepages
            if (ext4_has_inline_data(inode))
              BUG_ON(ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA))

The root cause of this issue is we destory inline data until call
ext4_writepages under delay allocation mode.  But there maybe already
convert from inline to extent.  To solve this issue, we call
filemap_flush first..
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/013f12bdedb96816aaa27ee04349f4433d361f52; https://git.kernel.org/stable/c/18a759f7f99f0b65a08ff5b7e745fc405a42bde4; https://git.kernel.org/stable/c/19918ec7717d87d5ab825884a46b26b21375d7ce
CVE: CVE-2022-49348
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: filter out EXT4_FC_REPLAY from on-disk superblock field s_state

The EXT4_FC_REPLAY bit in sbi->s_mount_state is used to indicate that
we are in the middle of replay the fast commit journal.  This was
actually a mistake, since the sbi->s_mount_info is initialized from
es->s_state.  Arguably s_mount_state is misleadingly named, but the
name is historical --- s_mount_state and s_state dates back to ext2.

What should have been used is the ext4_{set,clear,test}_mount_flag()
inline functions, which sets EXT4_MF_* bits in sbi->s_mount_flags.

The problem with using EXT4_FC_REPLAY is that a maliciously corrupted
superblock could result in EXT4_FC_REPLAY getting set in
s_mount_state.  This bypasses some sanity checks, and this can trigger
a BUG() in ext4_es_cache_extent().  As a easy-to-backport-fix, filter
out the EXT4_FC_REPLAY bit for now.  We should eventually transition
away from EXT4_FC_REPLAY to something like EXT4_MF_REPLAY.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/55b4dbb29054a05d839562f6d635ce05669b016d; https://git.kernel.org/stable/c/af2f1932743fb52ebcb008ad7ac500d9df0aa796; https://git.kernel.org/stable/c/b99fd73418350dea360da8311e87a6a7b0e15a4c
CVE: CVE-2022-49350
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: mdio: unexport __init-annotated mdio_bus_init()

EXPORT_SYMBOL and __init is a bad combination because the .init.text
section is freed up after the initialization. Hence, modules cannot
use symbols annotated __init. The access to a freed symbol may end up
with kernel panic.

modpost used to detect it, but it has been broken for a decade.

Recently, I fixed modpost so it started to warn it again, then this
showed up in linux-next builds.

There are two ways to fix it:

  - Remove __init
  - Remove EXPORT_SYMBOL

I chose the latter for this case because the only in-tree call-site,
drivers/net/phy/phy_device.c is never compiled as modular.
(CONFIG_PHYLIB is boolean)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/35b42dce619701f1300fb8498dae82c9bb1f0263; https://git.kernel.org/stable/c/5534bcd7c[PII_REDACTED]7c4a8fd9c5031b3db1538; https://git.kernel.org/stable/c/59fa94cddf9eef8d8dae587373eed8b8f4eb11d7
CVE: CVE-2022-49351
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

net: altera: Fix refcount leak in altera_tse_mdio_create

Every iteration of for_each_child_of_node() decrements
the reference count of the previous node.
When break from a for_each_child_of_node() loop,
we need to explicitly call of_node_put() on the child node when
not need anymore.
Add missing of_node_put() to avoid refcount leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/11ec18b1d8d92b9df307d31950dcba0b3dd7283c; https://git.kernel.org/stable/c/1fd12298a0e0ca23478c715e672ee64c85670584; https://git.kernel.org/stable/c/4f850fe0a32c3f1e19b76996a3b1ca32637a14de
CVE: CVE-2022-49352
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix warning in ext4_handle_inode_extension

We got issue as follows:
EXT4-fs error (device loop0) in ext4_reserve_inode_write:5741: Out of memory
EXT4-fs error (device loop0): ext4_setattr:5462: inode #13: comm syz-executor.0: mark_inode_dirty error
EXT4-fs error (device loop0) in ext4_setattr:5519: Out of memory
EXT4-fs error (device loop0): ext4_ind_map_blocks:595: inode #13: comm syz-executor.0: Can't allocate blocks for non-extent mapped inodes with bigalloc
------------[ cut here ]------------
WARNING: CPU: 1 PID: 4361 at fs/ext4/file.c:301 ext4_file_write_iter+0x11c9/0x1220
Modules linked in:
CPU: 1 PID: 4361 Comm: syz-executor.0 Not tainted 5.10.0+ #1
RIP: 0010:ext4_file_write_iter+0x11c9/0x1220
RSP: 0018:ffff924d80b27c00 EFLAGS: 00010282
RAX: ffffffff815a3379 RBX: [PII_REDACTED] RCX: 000000003b000000
RDX: ffff924d81601000 RSI:[PII_REDACTED]0009cc RDI:[PII_REDACTED]0009cd
RBP:[PII_REDACTED]00000d R08: ffffffffbc5a2c6b R09: 0000902e0e52a96f
R10: ffff902e2b7c1b40 R11: ffff902e2b7c1b40 R12:[PII_REDACTED]00000a
R13: [PII_REDACTED] R14: ffff902e0e52aa10 R15: ffffffffffffff8b
FS:  00007f81a7f65700(0000) GS:ffff902e3bc80000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: ffffffffff600400 CR3: 000000012db88001 CR4:[PII_REDACTED]3706e0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 do_iter_readv_writev+0x2e5/0x360
 do_iter_write+0x112/0x4c0
 do_pwritev+0x1e5/0x390
 __x64_sys_pwritev2+0x7e/0xa0
 do_syscall_64+0x37/0x50
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Above issue may happen as follows:
Assume
inode.i_size=4096
EXT4_I(inode)->i_disksize=4096

step 1: set inode->i_isize = 8192
ext4_setattr
  if (attr->ia_size != inode->i_size)
    EXT4_I(inode)->i_disksize = attr->ia_size;
    rc = ext4_mark_inode_dirty
       ext4_reserve_inode_write
          ext4_get_inode_loc
            __ext4_get_inode_loc
              sb_getblk --> return -ENOMEM
   ...
   if (!error)  ->will not update i_size
     i_size_write(inode, attr->ia_size);
Now:
inode.i_size=4096
EXT4_I(inode)->i_disksize=8192

step 2: Direct write 4096 bytes
ext4_file_write_iter
 ext4_dio_write_iter
   iomap_dio_rw ->return error
 if (extend)
   ext4_handle_inode_extension
     WARN_ON_ONCE(i_size_read(inode) < EXT4_I(inode)->i_disksize);
->Then trigger warning.

To solve above issue, if mark inode dirty failed in ext4_setattr just
set 'EXT4_I(inode)->i_disksize' with old value.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1bcce88da60eccc946c0f4ed942b0f08cd565778; https://git.kernel.org/stable/c/adf490083ca52ebfb0b2fe64ff1ead00c0452dd7; https://git.kernel.org/stable/c/b81d2ff6885e38fc745eeaf[PII_REDACTED]778fc0b
CVE: CVE-2022-49353
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/papr_scm: don't requests stats with '0' sized stats buffer

Sachin reported [1] that on a POWER-10 lpar he is seeing a kernel panic being
reported with vPMEM when papr_scm probe is being called. The panic is of the
form below and is observed only with following option disabled(profile) for the
said LPAR 'Enable Performance Information Collection' in the HMC:

 Kernel attempted to write user page (1c) - exploit attempt? (uid: 0)
 BUG: Kernel NULL pointer dereference on write at 0x0000001c
 Faulting instruction address: 0xc008000001b90844
 Oops: Kernel access of bad area, sig: 11 [#1]
<snip>
 NIP [c008000001b90844] drc_pmem_query_stats+0x5c/0x270 [papr_scm]
 LR [c008000001b92794] papr_scm_probe+0x2ac/0x6ec [papr_scm]
 Call Trace:
       0xc[PII_REDACTED]1bca0 (unreliable)
       papr_scm_probe+0x2ac/0x6ec [papr_scm]
       platform_probe+0x98/0x150
       really_probe+0xfc/0x510
       __driver_probe_device+0x17c/0x230
<snip>
 ---[ end trace [PII_REDACTED] ]---
 Kernel panic - not syncing: Fatal exception

On investigation looks like this panic was caused due to a 'stat_buffer' of
size==0 being provided to drc_pmem_query_stats() to fetch all performance
stats-ids of an NVDIMM. However drc_pmem_query_stats() shouldn't have been called
since the vPMEM NVDIMM doesn't support and performance stat-id's. This was caused
due to missing check for 'p->stat_buffer_len' at the beginning of
papr_scm_pmu_check_events() which indicates that the NVDIMM doesn't support
performance-stats.

Fix this by introducing the check for 'p->stat_buffer_len' at the beginning of
papr_scm_pmu_check_events().

[1] https://lore.kernel.org/all/6B3A522A-6A5F-4CC9-B268-0C63AA6E07D3@linux.ibm.com
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/07bf9431b1590d1cd7a8d62075d0b50b073f0495; https://git.kernel.org/stable/c/e1295aab2ebcda1c1a9ed342baedc080e5c393e5
CVE: CVE-2022-49354
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ata: pata_octeon_cf: Fix refcount leak in octeon_cf_probe

of_find_device_by_node() takes reference, we should use put_device()
to release it when not need anymore.
Add missing put_device() to avoid refcount leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/10d6bdf532902be1d8aa5900b3c03c5671612aa2; https://git.kernel.org/stable/c/19cb3ece14547cb1ca2021798aaf49a3f82643d1; https://git.kernel.org/stable/c/7bd85c5ba1687daf54e3b6907673c3604b1e75cf
CVE: CVE-2022-49355
Published: 2025-02-26
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2022-49356
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

SUNRPC: Trap RDMA segment overflows

Prevent svc_rdma_build_writes() from walking off the end of a Write
chunk's segment array. Caught with KASAN.

The test that this fix replaces is invalid, and might have been left
over from an earlier prototype of the PCL work.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/659f7568e09593945c221bf20217a82ebdfe1328; https://git.kernel.org/stable/c/812c13521d4a72469c78ce06d8cdc8dc5b5557b5; https://git.kernel.org/stable/c/ea26bf5eca1459b5a7824997d7823409ce38214e
CVE: CVE-2022-49357
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

efi: Do not import certificates from UEFI Secure Boot for T2 Macs

On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables
at early boot to load UEFI Secure Boot certificates, a page fault occurs
in Apple firmware code and EFI runtime services are disabled with the
following logs:

[Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000
WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0
(Removed some logs from here)
Call Trace:
 <TASK>
 page_fault_oops+0x4f/0x2c0
 ? search_bpf_extables+0x6b/0x80
 ? search_module_extables+0x50/0x80
 ? search_exception_tables+0x5b/0x60
 kernelmode_fixup_or_oops+0x9e/0x110
 __bad_area_nosemaphore+0x155/0x190
 bad_area_nosemaphore+0x16/0x20
 do_kern_addr_fault+0x8c/0xa0
 exc_page_fault+0xd8/0x180
 asm_exc_page_fault+0x1e/0x30
(Removed some logs from here)
 ? __efi_call+0x28/0x30
 ? switch_mm+0x20/0x30
 ? efi_call_rts+0x19a/0x8e0
 ? process_one_work+0x222/0x3f0
 ? worker_thread+0x4a/0x3d0
 ? kthread+0x17a/0x1a0
 ? process_one_work+0x3f0/0x3f0
 ? set_kthread_struct+0x40/0x40
 ? ret_from_fork+0x22/0x30
 </TASK>
---[ end trace 1f82023595a5927f ]---
efi: Froze efi_rts_wq and disabled EFI Runtime Services
integrity: Couldn't get size: 0x[PII_REDACTED]000015
integrity: MODSIGN: Couldn't get UEFI db list
efi: EFI Runtime Services are disabled!
integrity: Couldn't get size: 0x[PII_REDACTED]000015
integrity: Couldn't get UEFI dbx list
integrity: Couldn't get size: 0x[PII_REDACTED]000015
integrity: Couldn't get mokx list
integrity: Couldn't get size: 0x80000000

So we avoid reading these UEFI variables and thus prevent the crash.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/155ca952c7ca19aa32ecfb7373a32bbc2e1ec6eb; https://git.kernel.org/stable/c/1f7264f0510f519b4e4f575a8f0579ea65e7592e; https://git.kernel.org/stable/c/65237307f88f5200782ae7f243bdd385e37cde5d