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

powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit

mpe: On 64-bit Book3E vmalloc space starts at 0x[PII_REDACTED]000000.

Because of the way __pa() works we have:
  __pa(0x[PII_REDACTED]000000) == 0, and therefore
  virt_to_pfn(0x[PII_REDACTED]000000) == 0, and therefore
  virt_addr_valid(0x[PII_REDACTED]000000) == true

Which is wrong, virt_addr_valid() should be false for vmalloc space.
In fact all vmalloc addresses that alias with a valid PFN will return
true from virt_addr_valid(). That can cause bugs with hardened usercopy
as described below by Kefeng Wang:

  When running ethtool eth0 on 64-bit Book3E, a BUG occurred:

    usercopy: Kernel memory exposure attempt detected from SLUB object not in SLUB page?! (offset 0, size 1048)!
    kernel BUG at mm/usercopy.c:99
    ...
    usercopy_abort+0x64/0xa0 (unreliable)
    __check_heap_object+0x168/0x190
    __check_object_size+0x1a0/0x200
    dev_ethtool+0x2494/0x2b20
    dev_ioctl+0x5d0/0x770
    sock_do_ioctl+0xf0/0x1d0
    sock_ioctl+0x3ec/0x5a0
    __se_sys_ioctl+0xf0/0x160
    system_call_exception+0xfc/0x1f0
    system_call_common+0xf8/0x200

  The code shows below,

    data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN));
    copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN))

  The data is alloced by vmalloc(), virt_addr_valid(ptr) will return true
  on 64-bit Book3E, which leads to the panic.

  As commit 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va
  and __pa addresses") does, make sure the virt addr above PAGE_OFFSET in
  the virt_addr_valid() for 64-bit, also add upper limit check to make
  sure the virt is below high_memory.

  Meanwhile, for 32-bit PAGE_OFFSET is the virtual address of the start
  of lowmem, high_memory is the upper low virtual address, the check is
  suitable for 32-bit, this will fix the issue mentioned in commit
  602946ec2f90 ("powerpc: Set max_mapnr correctly") too.

On 32-bit there is a similar problem with high memory, that was fixed in
commit 602946ec2f90 ("powerpc: Set max_mapnr correctly"), but that
commit breaks highmem and needs to be reverted.

We can't easily fix __pa(), we have code that relies on its current
behaviour. So for now add extra checks to virt_addr_valid().

For 64-bit Book3S the extra checks are not necessary, the combination of
virt_to_pfn() and pfn_valid() should yield the correct result, but they
are harmless.

[mpe: Add additional change log detail]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/a3727c25eacd7e437c4f560957fa3a376fe93e6b; https://git.kernel.org/stable/c/cbc065efcba000ad8f615f506ebe61b6d3c5145b; https://git.kernel.org/stable/c/d36febbcd537fcc50284e8b89609632d0146529f
CVE: CVE-2022-49068
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: release correct delalloc amount in direct IO write path

Running generic/406 causes the following WARNING in btrfs_destroy_inode()
which tells there are outstanding extents left.

In btrfs_get_blocks_direct_write(), we reserve a temporary outstanding
extents with btrfs_delalloc_reserve_metadata() (or indirectly from
btrfs_delalloc_reserve_space(()). We then release the outstanding extents
with btrfs_delalloc_release_extents(). However, the "len" can be modified
in the COW case, which releases fewer outstanding extents than expected.

Fix it by calling btrfs_delalloc_release_extents() for the original length.

To reproduce the warning, the filesystem should be 1 GiB.  It's
triggering a short-write, due to not being able to allocate a large
extent and instead allocating a smaller one.

  WARNING: CPU: 0 PID: 757 at fs/btrfs/inode.c:8848 btrfs_destroy_inode+0x1e6/0x210 [btrfs]
  Modules linked in: btrfs blake2b_generic xor lzo_compress
  lzo_decompress raid6_pq zstd zstd_decompress zstd_compress xxhash zram
  zsmalloc
  CPU: 0 PID: 757 Comm: umount Not tainted 5.17.0-rc8+ #101
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS d55cb5a 04/01/2014
  RIP: 0010:btrfs_destroy_inode+0x1e6/0x210 [btrfs]
  RSP: 0018:ffffc9000327bda8 EFLAGS: 00010206
  RAX: [PII_REDACTED] RBX: ffff888100548b78 RCX: [PII_REDACTED]
  RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: ffff888100548b78
  RBP: ffff[PII_REDACTED]40 R08: [PII_REDACTED] R09: ffff88810b48aba8
  R10: [PII_REDACTED] R11: ffff8881004eb240 R12: ffff88810b48a800
  R13: ffff88810b48ec08 R14: ffff88810b48ed00 R15: ffff888100490c68
  FS:  00007f8549ea0b80(0000) GS:ffff888237c00000(0000) knlGS:[PII_REDACTED]
  CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
  CR2: 00007f854a09e733 CR3: 000000010a2e9003 CR4:[PII_REDACTED]370eb0
  DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
  DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
  Call Trace:
   <TASK>
   destroy_inode+0x33/0x70
   dispose_list+0x43/0x60
   evict_inodes+0x161/0x1b0
   generic_shutdown_super+0x2d/0x110
   kill_anon_super+0xf/0x20
   btrfs_kill_super+0xd/0x20 [btrfs]
   deactivate_locked_super+0x27/0x90
   cleanup_mnt+0x12c/0x180
   task_work_run+0x54/0x80
   exit_to_user_mode_prepare+0x152/0x160
   syscall_exit_to_user_mode+0x12/0x30
   do_syscall_64+0x42/0x80
   entry_SYSCALL_64_after_hwframe+0x44/0xae
   RIP: 0033:0x7f854a000fb7
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/07cacfd9d9dc134557ac8866c73d570a59b3d1f3; https://git.kernel.org/stable/c/6d82ad13c4110e73c7b0392f00534a1502a1b520; https://git.kernel.org/stable/c/a04d37ddfe4be431b9e52e[PII_REDACTED]ab0a39a4
CVE: CVE-2022-49070
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

fbdev: Fix unregistering of framebuffers without device

OF framebuffers do not have an underlying device in the Linux
device hierarchy. Do a regular unregister call instead of hot
unplugging such a non-existing device. Fixes a NULL dereference.
An example error message on ppc64le is shown below.

  BUG: Kernel NULL pointer dereference on read at 0x00000060
  Faulting instruction address: 0xc[PII_REDACTED]0dfa4
  Oops: Kernel access of bad area, sig: 11 [#1]
  LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
  [...]
  CPU: 2 PID: 139 Comm: systemd-udevd Not tainted 5.17.0-ae085d7f9365 #1
  NIP:  c[PII_REDACTED]0dfa4 LR: c[PII_REDACTED]0df9c CTR: c[PII_REDACTED]97430
  REGS: c[PII_REDACTED]32fe0 TRAP: 0300   Not tainted  (5.17.0-ae085d7f9365)
  MSR:  [PII_REDACTED] <SF,VEC,EE,ME,IR,DR,RI,LE>  CR: 28228282  XER: 20000000
  CFAR: c[PII_REDACTED]0c80c DAR: [PII_REDACTED] DSISR: 40000000 IRQMASK: 0
  GPR00: c[PII_REDACTED]0df9c c[PII_REDACTED]33280 c[PII_REDACTED]9d200 [PII_REDACTED]
  GPR04: 00000000ffffefff c[PII_REDACTED]32f90 c[PII_REDACTED]32f88 [PII_REDACTED]
  GPR08: c[PII_REDACTED]658f8 c[PII_REDACTED]cd200 c[PII_REDACTED]f57d0 [PII_REDACTED]
  GPR12: [PII_REDACTED] c00000003fffe300 [PII_REDACTED] [PII_REDACTED]
  GPR16: [PII_REDACTED][PII_REDACTED]fc4a40 [PII_REDACTED][PII_REDACTED]fcfb80
  GPR20: 000001000f7283b0 [PII_REDACTED] c000000000e4a588 c000000000e4a5b0
  GPR24: [PII_REDACTED][PII_REDACTED]0a0000 c008000000db0168 c[PII_REDACTED]f6ec0
  GPR28: c[PII_REDACTED]d65a8 c000000004b36460 [PII_REDACTED] c[PII_REDACTED]d64b0
  NIP [c[PII_REDACTED]0dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0
  [c[PII_REDACTED]33280] [c[PII_REDACTED]0df9c] do_remove_conflicting_framebuffers+0x17c/0x1d0 (unreliable)
  [c[PII_REDACTED]33350] [c[PII_REDACTED]0e4d0] remove_conflicting_framebuffers+0x60/0x150
  [c[PII_REDACTED]333a0] [c[PII_REDACTED]0e6f4] remove_conflicting_pci_framebuffers+0x134/0x1b0
  [c[PII_REDACTED]33450] [c008000000e70438] drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm]
  [c[PII_REDACTED]33490] [c008000000da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs]
  [...]
  [c[PII_REDACTED]33db0] [c[PII_REDACTED]2aaa0] system_call_exception+0x170/0x2d0
  [c[PII_REDACTED]33e10] [c[PII_REDACTED]0c3cc] system_call_common+0xec/0x250

The bug [1] was introduced by commit 27599aacbaef ("fbdev: Hot-unplug
firmware fb devices on forced removal"). Most firmware framebuffers
have an underlying platform device, which can be hot-unplugged
before loading the native graphics driver. OF framebuffers do not
(yet) have that device. Fix the code by unregistering the framebuffer
as before without a hot unplug.

Tested with 5.17 on qemu ppc64le emulation.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/0f525289ff0ddeb380813bd81e0f9bdaaa1c9078; https://git.kernel.org/stable/c/2388f826cdc9af2651991adc0feb79de9bdf2232; https://git.kernel.org/stable/c/de33df481545974ba47c46f05194e769e4307843
CVE: CVE-2022-49071
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/panel: ili9341: fix optional regulator handling

If the optional regulator lookup fails, reset the pointer to NULL.
Other functions such as mipi_dbi_poweron_reset_conditional() only do
a NULL pointer check and will otherwise dereference the error pointer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/28dc1503a9d36654f9c61adb[PII_REDACTED]a30f71; https://git.kernel.org/stable/c/4ea189854b1e625ed5ec80d30147870f984db44c; https://git.kernel.org/stable/c/d14eb80e27795b7b20060f7b151cdfe39722a813
CVE: CVE-2022-49072
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

gpio: Restrict usage of GPIO chip irq members before initialization

GPIO chip irq members are exposed before they could be completely
initialized and this leads to race conditions.

One such issue was observed for the gc->irq.domain variable which
was accessed through the I2C interface in gpiochip_to_irq() before
it could be initialized by gpiochip_add_irqchip(). This resulted in
Kernel NULL pointer dereference.

Following are the logs for reference :-

kernel: Call Trace:
kernel:  gpiod_to_irq+0x53/0x70
kernel:  acpi_dev_gpio_irq_get_by+0x113/0x1f0
kernel:  i2c_acpi_get_irq+0xc0/0xd0
kernel:  i2c_device_probe+0x28a/0x2a0
kernel:  really_probe+0xf2/0x460
kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0

To avoid such scenarios, restrict usage of GPIO chip irq members before
they are completely initialized.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0912cf021fb5749372b3782611d8b1de4986c13a; https://git.kernel.org/stable/c/2c1fa3614795e2b24da1ba95de0b27b8f6ea4537; https://git.kernel.org/stable/c/5467801f1fcbdc46bc7298a84dbf3ca1ff2a7320
CVE: CVE-2022-49073
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ata: sata_dwc_460ex: Fix crash due to OOB write

the driver uses libata's "tag" values from in various arrays.
Since the mentioned patch bumped the ATA_TAG_INTERNAL to 32,
the value of the SATA_DWC_QCMD_MAX needs to account for that.

Otherwise ATA_TAG_INTERNAL usage cause similar crashes like
this as reported by Tice Rex on the OpenWrt Forum and
reproduced (with symbols) here:

| BUG: Kernel NULL pointer dereference at 0x00000000
| Faulting instruction address: 0xc03ed4b8
| Oops: Kernel access of bad area, sig: 11 [#1]
| BE PAGE_SIZE=4K PowerPC 44x Platform
| CPU: 0 PID: 362 Comm: scsi_eh_1 Not tainted 5.4.163 #0
| NIP:  c03ed4b8 LR: c03d27e8 CTR: c03ed36c
| REGS: cfa59950 TRAP: 0300   Not tainted  (5.4.163)
| MSR:  00021000 <CE,ME>  CR: 42000222  XER: 00000000
| DEAR: 00000000 ESR: 00000000
| GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...]
| [..]
| NIP [c03ed4b8] sata_dwc_qc_issue+0x14c/0x254
| LR [c03d27e8] ata_qc_issue+0x1c8/0x2dc
| Call Trace:
| [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (unreliable)
| [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc
| [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524
| [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0
| [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204
| [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130
| [...]

This is because sata_dwc_dma_xfer_complete() NULLs the
dma_pending's next neighbour "chan" (a *dma_chan struct) in
this '32' case right here (line ~735):
> hsdevp->dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE;

Then the next time, a dma gets issued; dma_dwc_xfer_setup() passes
the NULL'd hsdevp->chan to the dmaengine_slave_config() which then
causes the crash.

With this patch, SATA_DWC_QCMD_MAX is now set to ATA_MAX_QUEUE + 1.
This avoids the OOB. But please note, there was a worthwhile discussion
on what ATA_TAG_INTERNAL and ATA_MAX_QUEUE is. And why there should not
be a "fake" 33 command-long queue size.

Ideally, the dw driver should account for the ATA_TAG_INTERNAL.
In Damien Le Moal's words: "... having looked at the driver, it
is a bigger change than just faking a 33rd "tag" that is in fact
not a command tag at all."

BugLink: https://github.com/openwrt/openwrt/issues/9505
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/234c0132f76f0676d175757f61b0025191a3d935; https://git.kernel.org/stable/c/3a8751c0d4e24129e72dcec0139e99833b13904a; https://git.kernel.org/stable/c/55e1465ba79562a191708a40eeae3f8082a209e3
CVE: CVE-2022-49074
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

irqchip/gic-v3: Fix GICR_CTLR.RWP polling

It turns out that our polling of RWP is totally wrong when checking
for it in the redistributors, as we test the *distributor* bit index,
whereas it is a different bit number in the RDs... Oopsie boo.

This is embarassing. Not only because it is wrong, but also because
it took *8 years* to notice the blunder...

Just fix the damn thing.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0df6664531a12cdd8fc873f0cac0dcb40243d3e9; https://git.kernel.org/stable/c/3c07cc242baf83f0bddbbd9d7945d0bee56d8b57; https://git.kernel.org/stable/c/60e1eb4811f53f5f60c788297d978515e7a2637a
CVE: CVE-2022-49075
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: fix qgroup reserve overflow the qgroup limit

We use extent_changeset->bytes_changed in qgroup_reserve_data() to record
how many bytes we set for EXTENT_QGROUP_RESERVED state. Currently the
bytes_changed is set as "unsigned int", and it will overflow if we try to
fallocate a range larger than 4GiB. The result is we reserve less bytes
and eventually break the qgroup limit.

Unlike regular buffered/direct write, which we use one changeset for
each ordered extent, which can never be larger than 256M.  For
fallocate, we use one changeset for the whole range, thus it no longer
respects the 256M per extent limit, and caused the problem.

The following example test script reproduces the problem:

  $ cat qgroup-overflow.sh
  #!/bin/bash

  DEV=/dev/sdj
  MNT=/mnt/sdj

  mkfs.btrfs -f $DEV
  mount $DEV $MNT

  # Set qgroup limit to 2GiB.
  btrfs quota enable $MNT
  btrfs qgroup limit 2G $MNT

  # Try to fallocate a 3GiB file. This should fail.
  echo
  echo "Try to fallocate a 3GiB file..."
  fallocate -l 3G $MNT/3G.file

  # Try to fallocate a 5GiB file.
  echo
  echo "Try to fallocate a 5GiB file..."
  fallocate -l 5G $MNT/5G.file

  # See we break the qgroup limit.
  echo
  sync
  btrfs qgroup show -r $MNT

  umount $MNT

When running the test:

  $ ./qgroup-overflow.sh
  (...)

  Try to fallocate a 3GiB file...
  fallocate: fallocate failed: Disk quota exceeded

  Try to fallocate a 5GiB file...

  qgroupid         rfer         excl     max_rfer
  --------         ----         ----     --------
  0/5           5.00GiB      5.00GiB      2.00GiB

Since we have no control of how bytes_changed is used, it's better to
set it to u64.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/0355387ea5b02d353c9415613fab908fac5c52a6; https://git.kernel.org/stable/c/44277c50fdba5019ca25bfad1b71e2561b0de11b; https://git.kernel.org/stable/c/4b98799e181b4326a613108cf37acc1f55d21b45
CVE: CVE-2022-49076
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/hfi1: Fix use-after-free bug for mm struct

Under certain conditions, such as MPI_Abort, the hfi1 cleanup code may
represent the last reference held on the task mm.
hfi1_mmu_rb_unregister() then drops the last reference and the mm is freed
before the final use in hfi1_release_user_pages().  A new task may
allocate the mm structure while it is still being used, resulting in
problems. One manifestation is corruption of the mmap_sem counter leading
to a hang in down_write().  Another is corruption of an mm struct that is
in use by another task.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0b7186d657ee55e2cdefae498f07d5c1961e8023; https://git.kernel.org/stable/c/2bbac98d0930e8161b1957dc0ec99de39ade1b3c; https://git.kernel.org/stable/c/5a9a1b24ddb510715f8f[PII_REDACTED]86579a965c
CVE: CVE-2022-49077
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

mmmremap.c: avoid pointless invalidate_range_start/end on mremap(old_size=0)

If an mremap() syscall with old_size=0 ends up in move_page_tables(), it
will call invalidate_range_start()/invalidate_range_end() unnecessarily,
i.e.  with an empty range.

This causes a WARN in KVM's mmu_notifier.  In the past, empty ranges
have been diagnosed to be off-by-one bugs, hence the WARNing.  Given the
low (so far) number of unique reports, the benefits of detecting more
buggy callers seem to outweigh the cost of having to fix cases such as
this one, where userspace is doing something silly.  In this particular
case, an early return from move_page_tables() is enough to fix the
issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-193
References: https://git.kernel.org/stable/c/01e67e04c28170c47700c2c226d732bbfedb1ad0; https://git.kernel.org/stable/c/04bc13dae4a27b8d030843c85ae452bb2f1d9c1f; https://git.kernel.org/stable/c/2358aa84ef6dafcf544a557caaa6b91afb4a0bd2
CVE: CVE-2022-49078
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

lz4: fix LZ4_decompress_safe_partial read out of bound

When partialDecoding, it is EOF if we've either filled the output buffer
or can't proceed with reading an offset for following match.

In some extreme corner cases when compressed data is suitably corrupted,
UAF will occur.  As reported by KASAN [1], LZ4_decompress_safe_partial
may lead to read out of bound problem during decoding.  lz4 upstream has
fixed it [2] and this issue has been disscussed here [3] before.

current decompression routine was ported from lz4 v1.8.3, bumping
lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd
better fix it first.

[1] https://lore.kernel.org/all/[PII_REDACTED]00830d1205cf7f0477@google.com/
[2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad#
[3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/467d5e200ab4486b744fe1776154a43d1aa22d4b; https://git.kernel.org/stable/c/6adc01a7aa37445dafe8846faa0610a86029b253; https://git.kernel.org/stable/c/73953dfa9d50e5c9fe98ee13fd1d3427aa12a0a3
CVE: CVE-2022-49080
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/mempolicy: fix mpol_new leak in shared_policy_replace

If mpol_new is allocated but not used in restart loop, mpol_new will be
freed via mpol_put before returning to the caller.  But refcnt is not
initialized yet, so mpol_put could not do the right things and might
leak the unused mpol_new.  This would happen if mempolicy was updated on
the shared shmem file while the sp->lock has been dropped during the
memory allocation.

This issue could be triggered easily with the below code snippet if
there are many processes doing the below work at the same time:

  shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT);
  shm = shmat(shmid, 0, 0);
  loop many times {
    mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0);
    mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask,
          maxnode, 0);
  }
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/198932a14aeb19a15cf19e51e151d023bc4cd648; https://git.kernel.org/stable/c/25f506273b6ae806fd46bfcb6fdaa5b9ec81a05b; https://git.kernel.org/stable/c/39a32f3c06f6d68a530bf9612afa19f50f12e93d
CVE: CVE-2022-49081
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

highmem: fix checks in __kmap_local_sched_{in,out}

When CONFIG_DEBUG_KMAP_LOCAL is enabled __kmap_local_sched_{in,out} check
that even slots in the tsk->kmap_ctrl.pteval are unmapped.  The slots are
initialized with 0 value, but the check is done with pte_none.  0 pte
however does not necessarily mean that pte_none will return true.  e.g.
on xtensa it returns false, resulting in the following runtime warnings:

 WARNING: CPU: 0 PID: 101 at mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108
 CPU: 0 PID: 101 Comm: touch Not tainted 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13
 Call Trace:
   dump_stack+0xc/0x40
   __warn+0x8f/0x174
   warn_slowpath_fmt+0x48/0xac
   __kmap_local_sched_out+0x51/0x108
   __schedule+0x71a/0x9c4
   preempt_schedule_irq+0xa0/0xe0
   common_exception_return+0x5c/0x93
   do_wp_page+0x30e/0x330
   handle_mm_fault+0xa70/0xc3c
   do_page_fault+0x1d8/0x3c4
   common_exception+0x7f/0x7f

 WARNING: CPU: 0 PID: 101 at mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0
 CPU: 0 PID: 101 Comm: touch Tainted: G        W         5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13
 Call Trace:
   dump_stack+0xc/0x40
   __warn+0x8f/0x174
   warn_slowpath_fmt+0x48/0xac
   __kmap_local_sched_in+0x50/0xe0
   finish_task_switch$isra$0+0x1ce/0x2f8
   __schedule+0x86e/0x9c4
   preempt_schedule_irq+0xa0/0xe0
   common_exception_return+0x5c/0x93
   do_wp_page+0x30e/0x330
   handle_mm_fault+0xa70/0xc3c
   do_page_fault+0x1d8/0x3c4
   common_exception+0x7f/0x7f

Fix it by replacing !pte_none(pteval) with pte_val(pteval) != 0.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/66f133ceab7456c789f70a242991ed1b27ba1c3d; https://git.kernel.org/stable/c/7dd5b3b97716a611fcf67d92fd2370fcb8d50372; https://git.kernel.org/stable/c/85550b0f5fa5dd3c30469ea702c44444ef242c83