deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-49812
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

bridge: switchdev: Fix memory leaks when changing VLAN protocol

The bridge driver can offload VLANs to the underlying hardware either
via switchdev or the 8021q driver. When the former is used, the VLAN is
marked in the bridge driver with the 'BR_VLFLAG_ADDED_BY_SWITCHDEV'
private flag.

To avoid the memory leaks mentioned in the cited commit, the bridge
driver will try to delete a VLAN via the 8021q driver if the VLAN is not
marked with the previously mentioned flag.

When the VLAN protocol of the bridge changes, switchdev drivers are
notified via the 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but
the 8021q driver is also called to add the existing VLANs with the new
protocol and delete them with the old protocol.

In case the VLANs were offloaded via switchdev, the above behavior is
both redundant and buggy. Redundant because the VLANs are already
programmed in hardware and drivers that support VLAN protocol change
(currently only mlx5) change the protocol upon the switchdev attribute
notification. Buggy because the 8021q driver is called despite these
VLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to
memory leaks [1] when the VLANs are deleted.

Fix by not calling the 8021q driver for VLANs that were already
programmed via switchdev.

[1]
unreferenced object 0xffff8881f6771200 (size 256):
  comm "ip", pid 446855, jiffies[PII_REDACTED] (age 55.240s)
  hex dump (first 32 bytes):
    00 00 7f 0e 83 88 ff ff 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:
    [<[PII_REDACTED]2819ac>] vlan_vid_add+0x437/0x750
    [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920
    [<[PII_REDACTED]32b56f>] br_changelink+0x3d6/0x13f0
    [<[PII_REDACTED]d25f04>] __rtnl_newlink+0x8ae/0x14c0
    [<00000000f6276baf>] rtnl_newlink+0x5f/0x90
    [<[PII_REDACTED]6dc902>] rtnetlink_rcv_msg+0x336/0xa00
    [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340
    [<[PII_REDACTED]>] netlink_unicast+0x438/0x710
    [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40
    [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0
    [<[PII_REDACTED]1b8f91>] ____sys_sendmsg+0x4ff/0x6d0
    [<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0
    [<[PII_REDACTED]4f7e25>] __sys_sendmsg+0xab/0x130
    [<[PII_REDACTED]38b104>] do_syscall_64+0x3d/0x90
    [<[PII_REDACTED]ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/347f1793b573466424c550f2748ed837b6690fe7; https://git.kernel.org/stable/c/9d45921ee4cb364910097e7d1b7558559c2f9fd2; https://git.kernel.org/stable/c/f8926e2d2225eb7b7e11cd3fa266aaad9075b767
CVE: CVE-2022-49813
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

net: ena: Fix error handling in ena_init()

The ena_init() won't destroy workqueue created by
create_singlethread_workqueue() when pci_register_driver() failed.
Call destroy_workqueue() when pci_register_driver() failed to prevent the
resource leak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/0e2369223b174d198ec42a3ec0a7f06c8727b968; https://git.kernel.org/stable/c/3f7b2ef8fe924e299bc339811ea3f1b9935c040f; https://git.kernel.org/stable/c/6b23a4b252044e4fd23438930d452244818d7000
CVE: CVE-2022-49814
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

kcm: close race conditions on sk_receive_queue

sk->sk_receive_queue is protected by skb queue lock, but for KCM
sockets its RX path takes mux->rx_lock to protect more than just
skb queue. However, kcm_recvmsg() still only grabs the skb queue
lock, so race conditions still exist.

We can teach kcm_recvmsg() to grab mux->rx_lock too but this would
introduce a potential performance regression as struct kcm_mux can
be shared by multiple KCM sockets.

So we have to enforce skb queue lock in requeue_rx_msgs() and handle
skb peek case carefully in kcm_wait_data(). Fortunately,
skb_recv_datagram() already handles it nicely and is widely used by
other sockets, we can just switch to skb_recv_datagram() after
getting rid of the unnecessary sock lock in kcm_recvmsg() and
kcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,
so it is safe to get rid of this check too.

I ran the original syzbot reproducer for 30 min without seeing any
issue.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/22f6b5d47396b[PII_REDACTED]ee3f5c1f766cb4259; https://git.kernel.org/stable/c/4154b6afa2bd639214ff259d912faad984f7413a; https://git.kernel.org/stable/c/5121197ecc5db58c07da95eb1ff82b98b121a221
CVE: CVE-2022-49815
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

erofs: fix missing xas_retry() in fscache mode

The xarray iteration only holds the RCU read lock and thus may encounter
XA_RETRY_ENTRY if there's process modifying the xarray concurrently.
This will cause oops when referring to the invalid entry.

Fix this by adding the missing xas_retry(), which will make the
iteration wind back to the root node if XA_RETRY_ENTRY is encountered.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/37020bbb71d911431e16c2c940b97cf86ae4f2f6; https://git.kernel.org/stable/c/dbc98fe99e17ed18f2f272d5fe880d844b1c68c3
CVE: CVE-2022-49816
Published: 2025-05-01
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2022-49817
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

net: mhi: Fix memory leak in mhi_net_dellink()

MHI driver registers network device without setting the
needs_free_netdev flag, and does NOT call free_netdev() when
unregisters network device, which causes a memory leak.

This patch calls free_netdev() to fix it since netdev_priv
is used after unregister.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/25a270343b0f16e1f6e65f541a15975a35e238ff; https://git.kernel.org/stable/c/88da008e5e2f9753726ea5a51ef2eb144e9de927; https://git.kernel.org/stable/c/f7c125bd79f50ec[PII_REDACTED]be81d02726ec6f4
CVE: CVE-2022-49818
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

mISDN: fix misuse of put_device() in mISDN_register_device()

We should not release reference by put_device() before calling device_initialize().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2d25107e111a85c56f601a5470f1780ec054e6ac; https://git.kernel.org/stable/c/44658d65f6b3118f595a1229d7eed74845a5e2ac; https://git.kernel.org/stable/c/596230471da3415e92ae6b9d2a4e26f4a81cac5a
CVE: CVE-2022-49819
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

octeon_ep: fix potential memory leak in octep_device_setup()

When occur unsupported_dev and mbox init errors, it did not free oct->conf
and iounmap() oct->mmio[i].hw_addr. That would trigger memory leak problem.
Add kfree() for oct->conf and iounmap() for oct->mmio[i].hw_addr under
unsupported_dev and mbox init errors to fix the problem.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/67b65a0db8a7fdad43159819f41335497a4bb04f; https://git.kernel.org/stable/c/e4041be97b15302ebfffda8bbd45f3b2d096048f
CVE: CVE-2022-49820
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

mctp i2c: don't count unused / invalid keys for flow release

We're currently hitting the WARN_ON in mctp_i2c_flow_release:

    if (midev->release_count > midev->i2c_lock_count) {
        WARN_ONCE(1, "release count overflow");

This may be hit if we expire a flow before sending the first packet it
contains - as we will not be pairing the increment of release_count
(performed on flow release) with the i2c lock operation (only
performed on actual TX).

To fix this, only release a flow if we've encountered it previously (ie,
dev_flow_state does not indicate NEW), as we will mark the flow as
ACTIVE at the same time as accounting for the i2c lock operation. We
also need to add an INVALID flow state, to indicate when we've done the
release.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/9cbd48d5fa14e4c65f8580de16686077f7cea02b; https://git.kernel.org/stable/c/a5915a9a3ab4067ef8996a57738d156eabeb3a12
CVE: CVE-2022-49821
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

mISDN: fix possible memory leak in mISDN_dsp_element_register()

Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's
bus_id string array"), the name of device is allocated dynamically,
use put_device() to give up the reference, so that the name can be
freed in kobject_cleanup() when the refcount is 0.

The 'entry' is going to be freed in mISDN_dsp_dev_release(), so the
kfree() is removed. list_del() is called in mISDN_dsp_dev_release(),
so it need be initialized.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/083a2c9ef82e184bdf0b9f9a1e5fc38d32afbb47; https://git.kernel.org/stable/c/0f2c681900a01e3f23789bca26d88268c3d5b51d; https://git.kernel.org/stable/c/727ed7d28348c026c7ef4d852f3d0e5054d376e8
CVE: CVE-2022-49822
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix connections leak when tlink setup failed

If the tlink setup failed, lost to put the connections, then
the module refcnt leak since the cifsd kthread not exit.

Also leak the fscache info, and for next mount with fsc, it will
print the follow errors:
  CIFS: Cache volume key already in use (cifs,127.0.0.1:445,TEST)

Let's check the result of tlink setup, and do some cleanup.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0a087842d10b5daa123ee5291e386cdd78413705; https://git.kernel.org/stable/c/1dcdf5f5b2137185cbdd5385f29949ab3da4f00c; https://git.kernel.org/stable/c/a9059e338fc000c0b87d8cf29e93c74fd703212e
CVE: CVE-2022-49823
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ata: libata-transport: fix error handling in ata_tdev_add()

In ata_tdev_add(), the return value of transport_add_device() is
not checked. As a result, it causes null-ptr-deref while removing
the module, because transport_remove_device() is called to remove
the device that was not added.

Unable to handle kernel NULL pointer dereference at virtual address[PII_REDACTED]0000d0
CPU: 13 PID: 13603 Comm: rmmod Kdump: loaded Tainted: G        W          6.1.0-rc3+ #36
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : device_del+0x48/0x3a0
lr : device_del+0x44/0x3a0
Call trace:
 device_del+0x48/0x3a0
 attribute_container_class_device_del+0x28/0x40
 transport_remove_classdev+0x60/0x7c
 attribute_container_device_trigger+0x118/0x120
 transport_remove_device+0x20/0x30
 ata_tdev_delete+0x24/0x50 [libata]
 ata_tlink_delete+0x40/0xa0 [libata]
 ata_tport_delete+0x2c/0x60 [libata]
 ata_port_detach+0x148/0x1b0 [libata]
 ata_pci_remove_one+0x50/0x80 [libata]
 ahci_remove_one+0x4c/0x8c [ahci]

Fix this by checking and handling return value of transport_add_device()
in ata_tdev_add(). In the error path, device_del() is called to delete
the device which was added earlier in this function, and ata_tdev_free()
is called to free ata_dev.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1ff36351309e3eadcff297480baf4785e726de9b; https://git.kernel.org/stable/c/ef2ac07ab83163b9a53f45da20e14302591ad9cc; https://git.kernel.org/stable/c/f23058dc2398db1d8faca9a2b1ce30b85cdd8b22
CVE: CVE-2022-49824
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ata: libata-transport: fix error handling in ata_tlink_add()

In ata_tlink_add(), the return value of transport_add_device() is
not checked. As a result, it causes null-ptr-deref while removing
the module, because transport_remove_device() is called to remove
the device that was not added.

Unable to handle kernel NULL pointer dereference at virtual address[PII_REDACTED]0000d0
CPU: 33 PID: 13850 Comm: rmmod Kdump: loaded Tainted: G        W          6.1.0-rc3+ #12
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : device_del+0x48/0x39c
lr : device_del+0x44/0x39c
Call trace:
 device_del+0x48/0x39c
 attribute_container_class_device_del+0x28/0x40
 transport_remove_classdev+0x60/0x7c
 attribute_container_device_trigger+0x118/0x120
 transport_remove_device+0x20/0x30
 ata_tlink_delete+0x88/0xb0 [libata]
 ata_tport_delete+0x2c/0x60 [libata]
 ata_port_detach+0x148/0x1b0 [libata]
 ata_pci_remove_one+0x50/0x80 [libata]
 ahci_remove_one+0x4c/0x8c [ahci]

Fix this by checking and handling return value of transport_add_device()
in ata_tlink_add().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/67b219314628b90b3a314528e177335b0cd5c70b; https://git.kernel.org/stable/c/7377a14598f6b04446c54bc4a50cd249470d6c6f; https://git.kernel.org/stable/c/cf0816f6322c5c37ee52655f928e91ecf32da103
CVE: CVE-2022-49825
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ata: libata-transport: fix error handling in ata_tport_add()

In ata_tport_add(), the return value of transport_add_device() is
not checked. As a result, it causes null-ptr-deref while removing
the module, because transport_remove_device() is called to remove
the device that was not added.

Unable to handle kernel NULL pointer dereference at virtual address[PII_REDACTED]0000d0
CPU: 12 PID: 13605 Comm: rmmod Kdump: loaded Tainted: G        W          6.1.0-rc3+ #8
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : device_del+0x48/0x39c
lr : device_del+0x44/0x39c
Call trace:
 device_del+0x48/0x39c
 attribute_container_class_device_del+0x28/0x40
 transport_remove_classdev+0x60/0x7c
 attribute_container_device_trigger+0x118/0x120
 transport_remove_device+0x20/0x30
 ata_tport_delete+0x34/0x60 [libata]
 ata_port_detach+0x148/0x1b0 [libata]
 ata_pci_remove_one+0x50/0x80 [libata]
 ahci_remove_one+0x4c/0x8c [ahci]

Fix this by checking and handling return value of transport_add_device()
in ata_tport_add().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3613dbe3909dcc637fe6be00e4dc43b4aa0470ee; https://git.kernel.org/stable/c/52d9bb0adae9359711a0c5271430afd3754069e7; https://git.kernel.org/stable/c/b5362dc1634d8b8d5f30920f33ac11a3276b7ed9
CVE: CVE-2022-49826
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ata: libata-transport: fix double ata_host_put() in ata_tport_add()

In the error path in ata_tport_add(), when calling put_device(),
ata_tport_release() is called, it will put the refcount of 'ap->host'.

And then ata_host_put() is called again, the refcount is decreased
to 0, ata_host_release() is called, all ports are freed and set to
null.

When unbinding the device after failure, ata_host_stop() is called
to release the resources, it leads a null-ptr-deref(), because all
the ports all freed and null.

Unable to handle kernel NULL pointer dereference at virtual address [PII_REDACTED]
CPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G            E      6.1.0-rc3+ #8
pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : ata_host_stop+0x3c/0x84 [libata]
lr : release_nodes+0x64/0xd0
Call trace:
 ata_host_stop+0x3c/0x84 [libata]
 release_nodes+0x64/0xd0
 devres_release_all+0xbc/0x1b0
 device_unbind_cleanup+0x20/0x70
 really_probe+0x158/0x320
 __driver_probe_device+0x84/0x120
 driver_probe_device+0x44/0x120
 __driver_attach+0xb4/0x220
 bus_for_each_dev+0x78/0xdc
 driver_attach+0x2c/0x40
 bus_add_driver+0x184/0x240
 driver_register+0x80/0x13c
 __pci_register_driver+0x4c/0x60
 ahci_pci_driver_init+0x30/0x1000 [ahci]

Fix this by removing redundant ata_host_put() in the error path.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/30e12e2be27ac6c4be2af4163c70db381364706f; https://git.kernel.org/stable/c/377ff82c33c0cb74562a353361b64b33c09562cf; https://git.kernel.org/stable/c/865a6da40ba092c18292ae5f[PII_REDACTED]293745
CVE: CVE-2022-49827
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm: Fix potential null-ptr-deref in drm_vblank_destroy_worker()

drm_vblank_init() call drmm_add_action_or_reset() with
drm_vblank_init_release() as action. If __drmm_add_action() failed, will
directly call drm_vblank_init_release() with the vblank whose worker is
NULL. As the resule, a null-ptr-deref will happen in
kthread_destroy_worker(). Add the NULL check before calling
drm_vblank_destroy_worker().

BUG: null-ptr-deref
KASAN: null-ptr-deref in range [0x[PII_REDACTED]000068-0x[PII_REDACTED]00006f]
CPU: 5 PID: 961 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf-dirty
RIP: 0010:kthread_destroy_worker+0x25/0xb0
  Call Trace:
    <TASK>
    drm_vblank_init_release+0x124/0x220 [drm]
    ? drm_crtc_vblank_restore+0x8b0/0x8b0 [drm]
    __drmm_add_action_or_reset+0x41/0x50 [drm]
    drm_vblank_init+0x282/0x310 [drm]
    vkms_init+0x35f/0x1000 [vkms]
    ? 0xffffffffc4508000
    ? lock_is_held_type+0xd7/0x130
    ? __kmem_cache_alloc_node+0x1c2/0x2b0
    ? lock_is_held_type+0xd7/0x130
    ? 0xffffffffc4508000
    do_one_initcall+0xd0/0x4f0
    ...
    do_syscall_64+0x35/0x80
    entry_SYSCALL_64_after_hwframe+0x46/0xb0
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1d160dfb3fdf11ba9447e862c548447f91f4e74a; https://git.kernel.org/stable/c/3acd2016421b2e628acad65495d15493bf7a3bc3; https://git.kernel.org/stable/c/4979524f5a2a8210e87fde2f642b0dc060860821
CVE: CVE-2022-49828
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

hugetlbfs: don't delete error page from pagecache

This change is very similar to the change that was made for shmem [1], and
it solves the same problem but for HugeTLBFS instead.

Currently, when poison is found in a HugeTLB page, the page is removed
from the page cache.  That means that attempting to map or read that
hugepage in the future will result in a new hugepage being allocated
instead of notifying the user that the page was poisoned.  As [1] states,
this is effectively memory corruption.

The fix is to leave the page in the page cache.  If the user attempts to
use a poisoned HugeTLB page with a syscall, the syscall will fail with
EIO, the same error code that shmem uses.  For attempts to map the page,
the thread will get a BUS_MCEERR_AR SIGBUS.

[1]: commit a[PII_REDACTED]1 ("mm: shmem: don't truncate page if memory failure happens")
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/30571f28bb35c826219971c63bcf60d2517112ed; https://git.kernel.org/stable/c/8625147cafaa9ba74713d682f5185eb62cb2aedb; https://git.kernel.org/stable/c/ec667443b2dbc6cdbbac4073e51a17733158ec6a
CVE: CVE-2022-49829
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/scheduler: fix fence ref counting

We leaked dependency fences when processes were beeing killed.

Additional to that grab a reference to the last scheduled fence.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/b3af84383e7abdc5e63435817bb73a268e7c3637; https://git.kernel.org/stable/c/e5f4b38362df93594cb426b04979d8834122f159
CVE: CVE-2022-49830
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/drv: Fix potential memory leak in drm_dev_init()

drm_dev_init() will add drm_dev_init_release() as a callback. When
drmm_add_action() failed, the release function won't be added. As the
result, the ref cnt added by device_get() in drm_dev_init() won't be put
by drm_dev_init_release(), which leads to the memleak. Use
drmm_add_action_or_reset() instead of drmm_add_action() to prevent
memleak.

unreferenced object 0xffff88810bc0c800 (size 2048):
  comm "modprobe", pid 8322, jiffies[PII_REDACTED] (age 15.292s)
  hex dump (first 32 bytes):
    e8 cc c0 0b 81 88 ff ff ff ff ff ff 00 00 00 00  ................
    20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff   $<.............
  backtrace:
    [<[PII_REDACTED]51f72d>] __kmalloc+0x4b/0x1c0
    [<[PII_REDACTED]f21f26>] platform_device_alloc+0x2d/0xe0
    [<[PII_REDACTED]52a479>] platform_device_register_full+0x24/0x1c0
    [<[PII_REDACTED]f4ea61>] 0xffffffffa0736051
    [<[PII_REDACTED]5b2441>] do_one_initcall+0x7a/0x380
    [<[PII_REDACTED]a4a177>] do_init_module+0x5c/0x230
    [<000000002bf8a8e2>] load_module+0x227d/0x2420
    [<[PII_REDACTED]7d6d0a>] __do_sys_finit_module+0xd5/0x140
    [<00000000c99fc324>] do_syscall_64+0x3f/0x90
    [<000000004d85aa77>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/07e56de8766fe5be[PII_REDACTED]4b84ac0ec0de91; https://git.kernel.org/stable/c/bd8d1335e6e70a396094ef98913b513140c0b86b; https://git.kernel.org/stable/c/c47a823ea186263ab69cfb665327b7f72cb5e779
CVE: CVE-2022-49831
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: zoned: initialize device's zone info for seeding

When performing seeding on a zoned filesystem it is necessary to
initialize each zoned device's btrfs_zoned_device_info structure,
otherwise mounting the filesystem will cause a NULL pointer dereference.

This was uncovered by fstests' testcase btrfs/163.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/544f38a738343d7e75f104e5e9d1ade58d8b71bd; https://git.kernel.org/stable/c/91c38504e589dadbcde47b1cacdfc5b684154d44; https://git.kernel.org/stable/c/a8d1b1647bf8244a5f270538e9e636e2657fffa3
CVE: CVE-2022-49832
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map

Here is the BUG report by KASAN about null pointer dereference:

BUG: KASAN: null-ptr-deref in strcmp+0x2e/0x50
Read of size 1 at addr [PII_REDACTED] by task python3/2640
Call Trace:
 strcmp
 __of_find_property
 of_find_property
 pinctrl_dt_to_map

kasprintf() would return NULL pointer when kmalloc() fail to allocate.
So directly return ENOMEM, if kasprintf() return NULL pointer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/040f726fecd88121f3b95e70369785ad452dddf9; https://git.kernel.org/stable/c/5834a3a98cd266ad35a229923c0adbd0addc8d68; https://git.kernel.org/stable/c/777430aa4ddccaa5accec6db90ffc1d47f00d471
CVE: CVE-2022-49833
Published: 2025-05-01
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: zoned: clone zoned device info when cloning a device

When cloning a btrfs_device, we're not cloning the associated
btrfs_zoned_device_info structure of the device in case of a zoned
filesystem.

Later on this leads to a NULL pointer dereference when accessing the
device's zone_info for instance when setting a zone as active.

This was uncovered by fstests' testcase btrfs/161.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/21e61ec6d0bb786818490e926aa9aeb4de95ad0d; https://git.kernel.org/stable/c/ad88cabcec942c033f980cd1e28d56ecdaf5f3b8