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

can: isotp: sanitize CAN ID checks in isotp_bind()

Syzbot created an environment that lead to a state machine status that
can not be reached with a compliant CAN ID address configuration.
The provided address information consisted of CAN ID 0x6000001 and 0xC28001
which both boil down to 11 bit CAN IDs 0x001 in sending and receiving.

Sanitize the SFF/EFF CAN ID values before performing the address checks.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3ea566422cbde9610c2734980d1286ab681bb40e; https://git.kernel.org/stable/c/7b4652fc71dcec043977a6def80ef5034c913615; https://git.kernel.org/stable/c/cf522d741f5301223cc94b978eb1603c7590d65e
CVE: CVE-2022-49270
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

dm: fix use-after-free in dm_cleanup_zoned_dev()

dm_cleanup_zoned_dev() uses queue, so it must be called
before blk_cleanup_disk() starts its killing:

blk_cleanup_disk->blk_cleanup_queue()->kobject_put()->blk_release_queue()->
->...RCU...->blk_free_queue_rcu()->kmem_cache_free()

Otherwise, RCU callback may be executed first and
dm_cleanup_zoned_dev() will touch free'd memory:

 BUG: KASAN: use-after-free in dm_cleanup_zoned_dev+0x33/0xd0
 Read of size 8 at addr ffff88805ac6e430 by task dmsetup/681

 CPU: 4 PID: 681 Comm: dmsetup Not tainted 5.17.0-rc2+ #6
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
 Call Trace:
  <TASK>
  dump_stack_lvl+0x57/0x7d
  print_address_description.constprop.0+0x1f/0x150
  ? dm_cleanup_zoned_dev+0x33/0xd0
  kasan_report.cold+0x7f/0x11b
  ? dm_cleanup_zoned_dev+0x33/0xd0
  dm_cleanup_zoned_dev+0x33/0xd0
  __dm_destroy+0x26a/0x400
  ? dm_blk_ioctl+0x230/0x230
  ? up_write+0xd8/0x270
  dev_remove+0x156/0x1d0
  ctl_ioctl+0x269/0x530
  ? table_clear+0x140/0x140
  ? lock_release+0xb2/0x750
  ? remove_all+0x40/0x40
  ? rcu_read_lock_sched_held+0x12/0x70
  ? lock_downgrade+0x3c0/0x3c0
  ? rcu_read_lock_sched_held+0x12/0x70
  dm_ctl_ioctl+0xa/0x10
  __x64_sys_ioctl+0xb9/0xf0
  do_syscall_64+0x3b/0x90
  entry_SYSCALL_64_after_hwframe+0x44/0xae
 RIP: 0033:0x7fb6dfa95c27
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0987f00a76a17aa7213da492c00ed9e5a6210c73; https://git.kernel.org/stable/c/43a043aed964659bc69ef81f266912b73c80d837; https://git.kernel.org/stable/c/588b7f5df0cb64f281290c7672470c006abe7160
CVE: CVE-2022-49272
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock

syzbot caught a potential deadlock between the PCM
runtime->buffer_mutex and the mm->mmap_lock.  It was brought by the
recent fix to cover the racy read/write and other ioctls, and in that
commit, I overlooked a (hopefully only) corner case that may take the
revert lock, namely, the OSS mmap.  The OSS mmap operation
exceptionally allows to re-configure the parameters inside the OSS
mmap syscall, where mm->mmap_mutex is already held.  Meanwhile, the
copy_from/to_user calls at read/write operations also take the
mm->mmap_lock internally, hence it may lead to a AB/BA deadlock.

A similar problem was already seen in the past and we fixed it with a
refcount (in commit b248371628aa).  The former fix covered only the
call paths with OSS read/write and OSS ioctls, while we need to cover
the concurrent access via both ALSA and OSS APIs now.

This patch addresses the problem above by replacing the buffer_mutex
lock in the read/write operations with a refcount similar as we've
used for OSS.  The new field, runtime->buffer_accessing, keeps the
number of concurrent read/write operations.  Unlike the former
buffer_mutex protection, this protects only around the
copy_from/to_user() calls; the other codes are basically protected by
the PCM stream lock.  The refcount can be a negative, meaning blocked
by the ioctls.  If a negative value is seen, the read/write aborts
with -EBUSY.  In the ioctl side, OTOH, they check this refcount, too,
and set to a negative value for blocking unless it's already being
accessed.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/40f4cffbe13a51faf136faf5f9ef6847782cd595; https://git.kernel.org/stable/c/7777744e92a0b30e3e0cce2758d911837011ebd9; https://git.kernel.org/stable/c/7e9133607e1501c94881be35e118d8f84d96dcb4
CVE: CVE-2022-49273
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

rtc: pl031: fix rtc features null pointer dereference

When there is no interrupt line, rtc alarm feature is disabled.

The clearing of the alarm feature bit was being done prior to allocations
of ldata->rtc device, resulting in a null pointer dereference.

Clear RTC_FEATURE_ALARM after the rtc device is allocated.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/1b915703964f7e636961df04c540261dc55c6c70; https://git.kernel.org/stable/c/cd2722e411e8ab7e5ae41102f6925fa13dffdac5; https://git.kernel.org/stable/c/d274ce4a3dfd0b9a[PII_REDACTED]78359b865765cb
CVE: CVE-2022-49274
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix crash when mount with quota enabled

There is a reported crash when mounting ocfs2 with quota enabled.

  RIP: 0010:ocfs2_qinfo_lock_res_init+0x44/0x50 [ocfs2]
  Call Trace:
    ocfs2_local_read_info+0xb9/0x6f0 [ocfs2]
    dquot_load_quota_sb+0x216/0x470
    dquot_load_quota_inode+0x85/0x100
    ocfs2_enable_quotas+0xa0/0x1c0 [ocfs2]
    ocfs2_fill_super.cold+0xc8/0x1bf [ocfs2]
    mount_bdev+0x185/0x1b0
    legacy_get_tree+0x27/0x40
    vfs_get_tree+0x25/0xb0
    path_mount+0x465/0xac0
    __x64_sys_mount+0x103/0x140

It is caused by when initializing dqi_gqlock, the corresponding dqi_type
and dqi_sb are not properly initialized.

This issue is introduced by commit 6c85c2c72819, which wants to avoid
accessing uninitialized variables in error cases.  So make global quota
info properly initialized.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/01931e1c4e3de5d777253acae64c0e8fd071a1dd; https://git.kernel.org/stable/c/7c5312fdb1dcfdc1951b018669af88d5d6420b31; https://git.kernel.org/stable/c/de19433423c7bedabbd4f9a25f7dbc62c5e78921
CVE: CVE-2022-49275
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

can: m_can: m_can_tx_handler(): fix use after free of skb

can_put_echo_skb() will clone skb then free the skb. Move the
can_put_echo_skb() for the m_can version 3.0.x directly before the
start of the xmit in hardware, similar to the 3.1.x branch.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/08d90846e438ac22dc56fc49ec0b0d195831c5ed; https://git.kernel.org/stable/c/2e8e79c416aae1de224c0f1860f2e3350fa171f8; https://git.kernel.org/stable/c/[PII_REDACTED]3f302d26ab66b3abc098d43227b835
CVE: CVE-2022-49277
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

jffs2: fix memory leak in jffs2_do_mount_fs

If jffs2_build_filesystem() in jffs2_do_mount_fs() returns an error,
we can observe the following kmemleak report:

--------------------------------------------
unreferenced object 0xffff88811b25a640 (size 64):
  comm "mount", pid 691, jiffies[PII_REDACTED] (age 71.952s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffffa493be24>] kmem_cache_alloc_trace+0x584/0x880
    [<ffffffffa5423a06>] jffs2_sum_init+0x86/0x130
    [<ffffffffa5400e58>] jffs2_do_mount_fs+0x798/0xac0
    [<ffffffffa540acf3>] jffs2_do_fill_super+0x383/0xc30
    [<ffffffffa540c00a>] jffs2_fill_super+0x2ea/0x4c0
    [...]
unreferenced object 0xffff88812c760000 (size 65536):
  comm "mount", pid 691, jiffies[PII_REDACTED] (age 71.952s)
  hex dump (first 32 bytes):
    bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb  ................
    bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb  ................
  backtrace:
    [<ffffffffa493a449>] __kmalloc+0x6b9/0x910
    [<ffffffffa5423a57>] jffs2_sum_init+0xd7/0x130
    [<ffffffffa5400e58>] jffs2_do_mount_fs+0x798/0xac0
    [<ffffffffa540acf3>] jffs2_do_fill_super+0x383/0xc30
    [<ffffffffa540c00a>] jffs2_fill_super+0x2ea/0x4c0
    [...]
--------------------------------------------

This is because the resources allocated in jffs2_sum_init() are not
released. Call jffs2_sum_exit() to release these resources to solve
the problem.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/0978e9af4559a171ac7a74a1b3ef21804b0a0fa9; https://git.kernel.org/stable/c/2a9d[PII_REDACTED]e6bf2f40d0e677fc85e2dd3834; https://git.kernel.org/stable/c/4392e8aeebc5a4f8073620bccba7de1b1f6d7c88
CVE: CVE-2022-49278
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

remoteproc: Fix count check in rproc_coredump_write()

Check count for 0, to avoid a potential underflow. Make the check the
same as the one in rproc_recovery_write().
CVSS Score: 7.1 (HIGH)
CWE: CWE-191
References: https://git.kernel.org/stable/c/11572dad9fbadbd9269a2550f7e236b5b8c2d80c; https://git.kernel.org/stable/c/34afac3c75fa08d6fabbab4c93f0a90618afaaa6; https://git.kernel.org/stable/c/a8c3e53517985d69040a1b36a269e85f99cf0cea
CVE: CVE-2022-49279
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

NFSD: prevent integer overflow on 32 bit systems

On a 32 bit system, the "len * sizeof(*p)" operation can have an
integer overflow.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/23a9dbbe0faf124fc4c139615633b9d12a3a89ef; https://git.kernel.org/stable/c/303cd6173dce0a28d26526c77814eb90a41bd898; https://git.kernel.org/stable/c/3a2789e8ccb4a3e2a631f6817a2d3bb98b8c4fd8
CVE: CVE-2022-49280
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

NFSD: prevent underflow in nfssvc_decode_writeargs()

Smatch complains:

	fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs()
	warn: no lower bound on 'args->len'

Change the type to unsigned to prevent this issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-191, CWE-191
References: https://git.kernel.org/stable/c/184416d4b98509fb4c3d8fc3d6dc1437896cc159; https://git.kernel.org/stable/c/2764af8ce0bf03cc43ee4a11897cab96bde6caae; https://git.kernel.org/stable/c/413d8fefafe531a9442bb623e3fe292a38f88d65
CVE: CVE-2022-49281
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: fix handlecache and multiuser

In multiuser each individual user has their own tcon structure for the
share and thus their own handle for a cached directory.
When we umount such a share we much make sure to release the pinned down dentry
for each such tcon and not just the master tcon.

Otherwise we will get nasty warnings on umount that dentries are still in use:
[ 3459.590047] BUG: Dentry[PII_REDACTED]5c6f41{i=[PII_REDACTED]d95,n=/}  still in use\
 (2) [unmount of cifs cifs]
...
[ 3459.590492] Call Trace:
[ 3459.590500]  d_walk+0x61/0x2a0
[ 3459.590518]  ? shrink_lock_dentry.part.0+0xe0/0xe0
[ 3459.590526]  shrink_dcache_for_umount+0x49/0x110
[ 3459.590535]  generic_shutdown_super+0x1a/0x110
[ 3459.590542]  kill_anon_super+0x14/0x30
[ 3459.590549]  cifs_kill_sb+0xf5/0x104 [cifs]
[ 3459.590773]  deactivate_locked_super+0x36/0xa0
[ 3459.590782]  cleanup_mnt+0x131/0x190
[ 3459.590789]  task_work_run+0x5c/0x90
[ 3459.590798]  exit_to_user_mode_loop+0x151/0x160
[ 3459.590809]  exit_to_user_mode_prepare+0x83/0xd0
[ 3459.590818]  syscall_exit_to_user_mode+0x12/0x30
[ 3459.590828]  do_syscall_64+0x48/0x90
[ 3459.590833]  entry_SYSCALL_64_after_hwframe+0x44/0xae
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2fafbc[PII_REDACTED]3c106d1ec9b516da692059f; https://git.kernel.org/stable/c/47178c7722ac528ea08aa82c3ef9ffa178962d7a; https://git.kernel.org/stable/c/e71f6a3a1d5c826a30384fec587ca7503ef6bde5
CVE: CVE-2022-49283
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware: sysfb: fix platform-device leak in error path

Make sure to free the platform device also in the unlikely event that
registration fails.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/202c08914ba50dd324e42d5ad99535a89f242560; https://git.kernel.org/stable/c/b3e38f939ab4d0d86f56bff3362c3f88c4b2ad32; https://git.kernel.org/stable/c/bb7fcbe80a013dc883181dc818c407d38558f76c
CVE: CVE-2022-49284
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

coresight: syscfg: Fix memleak on registration failure in cscfg_create_device

device_register() calls device_initialize(),
according to doc of device_initialize:

    Use put_device() to give up your reference instead of freeing
    * @dev directly once you have called this function.

To prevent potential memleak, use put_device() for error handling.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/412225b32986d5b11c3c1ad9234c50a3f5c52c76; https://git.kernel.org/stable/c/a529af1f5a5c096f3e18f0d5a32cfcc3d82df1ec; https://git.kernel.org/stable/c/c61e2fc87f24cae4701f352fe9ecd4c5c143106c
CVE: CVE-2022-49285
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: accel: mma8452: use the correct logic to get mma8452_data

The original logic to get mma8452_data is wrong, the *dev point to
the device belong to iio_dev. we can't use this dev to find the
correct i2c_client. The original logic happen to work because it
finally use dev->driver_data to get iio_dev. Here use the API
to_i2c_client() is wrong and make reader confuse. To correct the
logic, it should be like this

  struct mma8452_data *data = iio_priv(dev_get_drvdata(dev));

But after commit 8b7651f25962 ("iio: iio_device_alloc(): Remove
unnecessary self drvdata"), the upper logic also can't work.
When try to show the avialable scale in userspace, will meet kernel
dump, kernel handle NULL pointer dereference.

So use dev_to_iio_dev() to correct the logic.

Dual fixes tags as the second reflects when the bug was exposed, whilst
the first reflects when the original bug was introduced.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/4c0bb583a4444cce224e8661090cbffc98e2fe07; https://git.kernel.org/stable/c/c87b7b12f48db86ac9909894f4dc0107d7df6375; https://git.kernel.org/stable/c/d2d9ebdbff79d87d27652578e6d1638ad3b5f3bf
CVE: CVE-2022-49286
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

tpm: use try_get_ops() in tpm-space.c

As part of the series conversion to remove nested TPM operations:

https://lore.kernel.org/all/[PII_REDACTED]4723.19671-1-jarkko.sakkinen@linux.intel.com/

exposure of the chip->tpm_mutex was removed from much of the upper
level code.  In this conversion, tpm2_del_space() was missed.  This
didn't matter much because it's usually called closely after a
converted operation, so there's only a very tiny race window where the
chip can be removed before the space flushing is done which causes a
NULL deref on the mutex.  However, there are reports of this window
being hit in practice, so fix this by converting tpm2_del_space() to
use tpm_try_get_ops(), which performs all the teardown checks before
acquring the mutex.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/476ddd23f818fb94cf86fb5617f3bb9a7c92113d; https://git.kernel.org/stable/c/5b1d2561a03e534064b51c50c774657833d3d2cf; https://git.kernel.org/stable/c/95193d12f10a8a088843b25e0f5fe1d83ec6b079
CVE: CVE-2022-49288
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: pcm: Fix races among concurrent prealloc proc writes

We have no protection against concurrent PCM buffer preallocation
changes via proc files, and it may potentially lead to UAF or some
weird problem.  This patch applies the PCM open_mutex to the proc
write operation for avoiding the racy proc writes and the PCM stream
open (and further operations).
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/37b12c16beb6f6c1c3c678c1aacbc46525c250f7; https://git.kernel.org/stable/c/51fce708ab8986a9879ee5da946a2cc120f1036d; https://git.kernel.org/stable/c/5ed8f8e3c4e59d0396b9ccf2e639711e24295bb6
CVE: CVE-2022-49289
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

uaccess: fix integer overflow on access_ok()

Three architectures check the end of a user access against the
address limit without taking a possible overflow into account.
Passing a negative length or another overflow in here returns
success when it should not.

Use the most common correct implementation here, which optimizes
for a constant 'size' argument, and turns the common case into a
single comparison.
CVSS Score: 7.1 (HIGH)
CWE: CWE-190
References: https://git.kernel.org/stable/c/222ca305c9fd39e5ed8104da25c09b2b79a516a8; https://git.kernel.org/stable/c/99801e2f457824955da4aadaa035913a6dede03a; https://git.kernel.org/stable/c/a1ad747fc1a0e06d1bf26b996ee8a56b5c8d02d8
CVE: CVE-2022-49290
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

mac80211: fix potential double free on mesh join

While commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving
mesh") fixed a memory leak on mesh leave / teardown it introduced a
potential memory corruption caused by a double free when rejoining the
mesh:

  ieee80211_leave_mesh()
  -> kfree(sdata->u.mesh.ie);
  ...
  ieee80211_join_mesh()
  -> copy_mesh_setup()
     -> old_ie = ifmsh->ie;
     -> kfree(old_ie);

This double free / kernel panics can be reproduced by using wpa_supplicant
with an encrypted mesh (if set up without encryption via "iw" then
ifmsh->ie is always NULL, which avoids this issue). And then calling:

  $ iw dev mesh0 mesh leave
  $ iw dev mesh0 mesh join my-mesh

Note that typically these commands are not used / working when using
wpa_supplicant. And it seems that wpa_supplicant or wpa_cli are going
through a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh join
where the NETDEV_UP resets the mesh.ie to NULL via a memcpy of
default_mesh_setup in cfg80211_netdev_notifier_call, which then avoids
the memory corruption, too.

The issue was first observed in an application which was not using
wpa_supplicant but "Senf" instead, which implements its own calls to
nl80211.

Fixing the issue by removing the kfree()'ing of the mesh IE in the mesh
join function and leaving it solely up to the mesh leave to free the
mesh IE.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415, CWE-415
References: https://git.kernel.org/stable/c/12e407a8ef17623823fd0c066fbd7f103953d28d; https://git.kernel.org/stable/c/273ebddc5fda2967492cb0b6cdd7d81cfb821b76; https://git.kernel.org/stable/c/3bbd0000d012f92aec423b224784fbf0f7bf40f8
CVE: CVE-2022-49291
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: pcm: Fix races among concurrent hw_params and hw_free calls

Currently we have neither proper check nor protection against the
concurrent calls of PCM hw_params and hw_free ioctls, which may result
in a UAF.  Since the existing PCM stream lock can't be used for
protecting the whole ioctl operations, we need a new mutex to protect
those racy calls.

This patch introduced a new mutex, runtime->buffer_mutex, and applies
it to both hw_params and hw_free ioctl code paths.  Along with it, the
both functions are slightly modified (the mmap_count check is moved
into the state-check block) for code simplicity.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0090c13cbbdffd7da079ac56f80373a9a1be0bf8; https://git.kernel.org/stable/c/0f6947f5f5208f6ebd4d76a82a4757e2839a23f8; https://git.kernel.org/stable/c/1bbf82d9f961414d6c76a08f7f843ea068e0ab7b
CVE: CVE-2022-49292
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: oss: Fix PCM OSS buffer allocation overflow

We've got syzbot reports hitting INT_MAX overflow at vmalloc()
allocation that is called from snd_pcm_plug_alloc().  Although we
apply the restrictions to input parameters, it's based only on the
hw_params of the underlying PCM device.  Since the PCM OSS layer
allocates a temporary buffer for the data conversion, the size may
become unexpectedly large when more channels or higher rates is given;
in the reported case, it went over INT_MAX, hence it hits WARN_ON().

This patch is an attempt to avoid such an overflow and an allocation
for too large buffers.  First off, it adds the limit of 1MB as the
upper bound for period bytes.  This must be large enough for all use
cases, and we really don't want to handle a larger temporary buffer
than this size.  The size check is performed at two places, where the
original period bytes is calculated and where the plugin buffer size
is calculated.

In addition, the driver uses array_size() and array3_size() for
multiplications to catch overflows for the converted period size and
buffer bytes.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/0c4190b41a69990666b4000999e27f8f1b2a426b; https://git.kernel.org/stable/c/5ce74ff7059341d8b2f4d01c3383491df63d1898; https://git.kernel.org/stable/c/7a40cbf3579a8e14849ba7ce46309c1992658d2b
CVE: CVE-2022-49293
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: initialize registers in nft_do_chain()

Initialize registers to avoid stack leak into userspace.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/06f0ff82c70241a766a811ae1acf07d6e2734dcb; https://git.kernel.org/stable/c/2c74374c2e88c7b7992bf808d9f9391f7452f9d9; https://git.kernel.org/stable/c/4c905f6740a365464e91467aa50916555b28213d
CVE: CVE-2022-49294
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check if modulo is 0 before dividing.

[How & Why]
If a value of 0 is read, then this will cause a divide-by-0 panic.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369, CWE-369
References: https://git.kernel.org/stable/c/07efce8269a038c37814eb656b4de14aa3015fc6; https://git.kernel.org/stable/c/10ef82d6e0af5536ec64770c07f6bbabfdd6977c; https://git.kernel.org/stable/c/49947b906a6bd9668eaf4f9cf691973c25c26955
CVE: CVE-2022-49295
Published: 2025-02-26
Description: In the Linux kernel, the following vulnerability has been resolved:

nbd: call genl_unregister_family() first in nbd_cleanup()

Otherwise there may be race between module removal and the handling of
netlink command, which can lead to the oops as shown below:

  BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
  Oops: 0002 [#1] SMP PTI
  CPU: 1 PID: 31299 Comm: nbd-client Tainted: G            E     5.14.0-rc4
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
  RIP: 0010:down_write+0x1a/0x50
  Call Trace:
   start_creating+0x89/0x130
   debugfs_create_dir+0x1b/0x130
   nbd_start_device+0x13d/0x390 [nbd]
   nbd_genl_connect+0x42f/0x748 [nbd]
   genl_family_rcv_msg_doit.isra.0+0xec/0x150
   genl_rcv_msg+0xe5/0x1e0
   netlink_rcv_skb+0x55/0x100
   genl_rcv+0x29/0x40
   netlink_unicast+0x1a8/0x250
   netlink_sendmsg+0x21b/0x430
   ____sys_sendmsg+0x2a4/0x2d0
   ___sys_sendmsg+0x81/0xc0
   __sys_sendmsg+0x62/0xb0
   __x64_sys_sendmsg+0x1f/0x30
   do_syscall_64+0x3b/0xc0
   entry_SYSCALL_64_after_hwframe+0x44/0xae
  Modules linked in: nbd(E-)
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/013a79f1b5c89290e2e97f1ebf14b14e0cf5fe5c; https://git.kernel.org/stable/c/06c4da89c24e7023ea448cadf8e9daf06a0aae6e; https://git.kernel.org/stable/c/1be608e1ee1f222464b2856bda9b85ab5184a33e