deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2023-53189
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv6/addrconf: fix a potential refcount underflow for idev

Now in addrconf_mod_rs_timer(), reference idev depends on whether
rs_timer is not pending. Then modify rs_timer timeout.

There is a time gap in [1], during which if the pending rs_timer
becomes not pending. It will miss to hold idev, but the rs_timer
is activated. Thus rs_timer callback function addrconf_rs_timer()
will be executed and put idev later without holding idev. A refcount
underflow issue for idev can be caused by this.

	if (!timer_pending(&idev->rs_timer))
		in6_dev_hold(idev);
		  <--------------[1]
	mod_timer(&idev->rs_timer, jiffies + when);

To fix the issue, hold idev if mod_timer() return 0.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-191
References: https://git.kernel.org/stable/c/06a0716949c22e2aefb[PII_REDACTED]71197151acc; https://git.kernel.org/stable/c/1f656e483eb4733d62f18dfb206a49b78f60f495; https://git.kernel.org/stable/c/2ad31ce40e8182860b631e37209e93e543790b7c
CVE: CVE-2023-53191
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

irqchip/alpine-msi: Fix refcount leak in alpine_msix_init_domains

of_irq_find_parent() returns a node pointer with refcount incremented,
We should use of_node_put() on it when not needed anymore.
Add missing of_node_put() to avoid refcount leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/071d068b89e95d1b078aa6bbcb9d0961b77d6aa1; https://git.kernel.org/stable/c/5fbf2cc39b62a4afe44f3d42ee3dcf8f012c1926; https://git.kernel.org/stable/c/65e30bd1310d90b794c377bf[PII_REDACTED]54aa30
CVE: CVE-2023-53193
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v10_0_hw_fini

The gmc.ecc_irq is enabled by firmware per IFWI setting,
and the host driver is not privileged to enable/disable
the interrupt. So, it is meaningless to use the amdgpu_irq_put
function in gmc_v10_0_hw_fini, which also leads to the call
trace.

[   82.340264] Call Trace:
[   82.340265]  <TASK>
[   82.340269]  gmc_v10_0_hw_fini+0x83/0xa0 [amdgpu]
[   82.340447]  gmc_v10_0_suspend+0xe/0x20 [amdgpu]
[   82.340623]  amdgpu_device_ip_suspend_phase2+0x127/0x1c0 [amdgpu]
[   82.340789]  amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu]
[   82.340955]  amdgpu_device_pre_asic_reset+0xdd/0x2b0 [amdgpu]
[   82.341122]  amdgpu_device_gpu_recover.cold+0x4dd/0xbb2 [amdgpu]
[   82.341359]  amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu]
[   82.341529]  process_one_work+0x21d/0x3f0
[   82.341535]  worker_thread+0x1fa/0x3c0
[   82.341538]  ? process_one_work+0x3f0/0x3f0
[   82.341540]  kthread+0xff/0x130
[   82.341544]  ? kthread_complete_and_exit+0x20/0x20
[   82.341547]  ret_from_fork+0x22/0x30
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/08c677cb0b436a96a836792bb35a8ec5de4999c2; https://git.kernel.org/stable/c/23febab57e345c0e66f8574c1018707e7eb6ea94; https://git.kernel.org/stable/c/59e2439111ac2bd24ea0cecf5825cf06684b2c6c
CVE: CVE-2023-53195
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

mlxsw: minimal: fix potential memory leak in mlxsw_m_linecards_init

The line cards array is not freed in the error path of
mlxsw_m_linecards_init(), which can lead to a memory leak. Fix by
freeing the array in the error path, thereby making the error path
identical to mlxsw_m_linecards_fini().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/08fc75735fda3be97194bfbf3c899c87abb3d0fe; https://git.kernel.org/stable/c/cd716022c968bc6748f23708b986f845b45791b7; https://git.kernel.org/stable/c/d4f5b1dd816dccd4ee6bb60b2a81a3d4373636a9
CVE: CVE-2023-53196
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3: qcom: Fix potential memory leak

Function dwc3_qcom_probe() allocates memory for resource structure
which is pointed by parent_res pointer. This memory is not
freed. This leads to memory leak. Use stack memory to prevent
memory leak.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/097fb3ee710d4de83b8d4f5589e8ee13e0f0541e; https://git.kernel.org/stable/c/134a7d4642f11daed6bbc378f930a54dd0322291; https://git.kernel.org/stable/c/648a163cff21ea355c8765e882ba8bf66a870a3e
CVE: CVE-2023-53197
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

USB: uhci: fix memory leak with using debugfs_lookup()

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time.  To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0a3f82c79c86278e7f144564b1cb6cc5c3657144; https://git.kernel.org/stable/c/9cb88847b8b86f[PII_REDACTED]2a23dca895b6f61; https://git.kernel.org/stable/c/c6af1dbc99ad37bf67c8703982df4d7f12d256c1
CVE: CVE-2025-10447
Published: 2025-09-15
Description: A vulnerability was detected in Campcodes Online Job Finder System 1.0. The impacted element is an unknown function of the file /eris/applicationform.php. The manipulation of the argument picture results in unrestricted upload. It is possible to launch the attack remotely. The exploit is now public and may be used.
CVSS Score: 7.3 (HIGH)
CWE: CWE-284, CWE-434
References: https://github.com/HAO-RAY/HCR-CVE/issues/6; https://vuldb.com/?ctiid.323881; https://vuldb.com/?id.323881
CVE: CVE-2025-10448
Published: 2025-09-15
Description: A flaw has been found in Campcodes Online Job Finder System 1.0. This affects an unknown function of the file /index.php?q=result&searchfor=bycompany. This manipulation of the argument Search causes sql injection. The attack can be initiated remotely. The exploit has been published and may be used.
CVSS Score: 7.3 (HIGH)
CWE: CWE-74, CWE-89
References: https://github.com/HAO-RAY/HCR-CVE/issues/7; https://vuldb.com/?ctiid.323882; https://vuldb.com/?id.323882
CVE: CVE-2025-46408
Published: 2025-09-15
Description: An issue was discovered in the methods push.lite.avtech.com.AvtechLib.GetHttpsResponse and push.lite.avtech.com.Push_HttpService.getNewHttpClient in AVTECH EagleEyes 2.0.0. The methods set ALLOW_ALL_HOSTNAME_VERIFIER, bypassing domain validation.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-297
References: https://github.com/shinyColumn/CVE-2025-46408; https://github.com/shinyColumn/CVE-2025-46408
CVE: CVE-2025-50110
Published: 2025-09-15
Description: An issue was discovered in the method push.lite.avtech.com.AvtechLib.GetHttpsResponse in AVTECH EagleEyes Lite 2.0.0, the GetHttpsResponse method transmits sensitive information - including internal server URLs, account IDs, passwords, and device tokens - as plaintext query parameters over HTTPS
CVSS Score: 8.8 (HIGH)
CWE: CWE-319, CWE-598
References: https://github.com/shinyColumn/CVE-2025-50110
CVE: CVE-2025-50944
Published: 2025-09-15
Description: An issue was discovered in the method push.lite.avtech.com.MySSLSocketFactoryNew.checkServerTrusted in AVTECH EagleEyes 2.0.0. The custom X509TrustManager used in checkServerTrusted only checks the certificate's expiration date, skipping proper TLS chain validation.
CVSS Score: 8.8 (HIGH)
CWE: CWE-295
References: https://github.com/shinyColumn/CVE-2025-50944; https://shinycolumn.notion.site/eagleeyes-lite
CVE: CVE-2025-56710
Published: 2025-09-15
Description: A Cross-Site Request Forgery (CSRF) vulnerability was identified in the Profile Page of the PHPGurukul Student-Result-Management-System-Using-PHP-V2.0. This flaw allows an attacker to trick authenticated users into unintentionally modifying their account details. By crafting a malicious HTML page, an attacker can submit unauthorized requests to the vulnerable endpoint: /create-class.php.
CVSS Score: 7.3 (HIGH)
CWE: CWE-352
References: https://medium.com/@mrshaikh841/csrf-pocs-1c96d9305298
CVE: CVE-2025-59376
Published: 2025-09-15
Description: feiskyer mcp-kubernetes-server through 0.1.11 does not consider chained commands in the implementation of --disable-write and --disable-delete, e.g., it allows a "kubectl version; kubectl delete pod" command because the first word (i.e., "version") is not a write or delete operation.
CVSS Score: 3.7 (LOW)
CWE: CWE-77, CWE-863
References: https://github.com/feiskyer/mcp-kubernetes-server/blob/78957b6c1a3982080cf6fcaac6f6e9014116a71c/src/mcp_kubernetes_server/main.py#L106-L137; https://github.com/william31212/CVE-Requests-1896609; https://github.com/william31212/CVE-Requests-1896609
CVE: CVE-2025-59377
Published: 2025-09-15
Description: feiskyer mcp-kubernetes-server through 0.1.11 allows OS command injection, even in read-only mode, via /mcp/kubectl because shell=True is used. NOTE: this is unrelated to mcp-server-kubernetes and CVE-2025-53355.
CVSS Score: 3.7 (LOW)
CWE: CWE-78, CWE-78
References: https://github.com/feiskyer/mcp-kubernetes-server/blob/78957b6c1a3982080cf6fcaac6f6e9014116a71c/src/mcp_kubernetes_server/command.py#L38; https://github.com/william31212/CVE-Requests-1896609; https://github.com/william31212/CVE-Requests-1896609
CVE: CVE-2022-50263
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

vdpasim: fix memory leak when freeing IOTLBs

After commit bda324fd037a ("vdpasim: control virtqueue support"),
vdpasim->iommu became an array of IOTLB, so we should clean the
mappings of each free one by one instead of just deleting the ranges
in the first IOTLB which may leak maps.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0b7a04a30eef20e6b24926a45c0ce7906ae85bd6; https://git.kernel.org/stable/c/16b22e27fba6fd816d0dcb98f42cc71f0836c27e; https://git.kernel.org/stable/c/54b210c90d2803a9f1c8fd2f0d08e90172e9a06d
CVE: CVE-2022-50264
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: socfpga: Fix memory leak in socfpga_gate_init()

Free @socfpga_clk and @ops on the error path to avoid memory leak issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0b8ba891ad4d1ef6bfa4c72efc83f9f9f855f68b; https://git.kernel.org/stable/c/3e8fd1d0fab4d5c9a50d225dddc207deac12f13a; https://git.kernel.org/stable/c/6f2198914fb9aac286a6ff6cf09b23752141e04f
CVE: CVE-2022-50265
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

kcm: annotate data-races around kcm->rx_wait

kcm->rx_psock can be read locklessly in kcm_rfree().
Annotate the read and writes accordingly.

syzbot reported:

BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfree

write to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1:
reserve_rx_kcm net/kcm/kcmsock.c:283 [inline]
kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363
__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301
strp_recv+0x6d/0x80 net/strparser/strparser.c:335
tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703
strp_read_sock net/strparser/strparser.c:358 [inline]
do_strp_work net/strparser/strparser.c:406 [inline]
strp_work+0xe8/0x180 net/strparser/strparser.c:415
process_one_work+0x3d3/0x720 kernel/workqueue.c:2289
worker_thread+0x618/0xa70 kernel/workqueue.c:2436
kthread+0x1a9/0x1e0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306

read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0:
kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181
skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841
skb_release_all net/core/skbuff.c:852 [inline]
__kfree_skb net/core/skbuff.c:868 [inline]
kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891
kfree_skb include/linux/skbuff.h:1216 [inline]
kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161
____sys_recvmsg+0x16c/0x2e0
___sys_recvmsg net/socket.c:2743 [inline]
do_recvmmsg+0x2f1/0x710 net/socket.c:2837
__sys_recvmmsg net/socket.c:2916 [inline]
__do_sys_recvmmsg net/socket.c:2939 [inline]
__se_sys_recvmmsg net/socket.c:2932 [inline]
__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

value changed: 0x01 -> 0x00

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0c745b5141a45a076f1cb9772a399f7ebcb0948a; https://git.kernel.org/stable/c/2733fb2ad5bfbe6538f2f93a21f2504e3dba9d6a; https://git.kernel.org/stable/c/62086d1c4602e4f2ec07b975165afc2ed0ff1be9
CVE: CVE-2022-50266
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

kprobes: Fix check for probe enabled in kill_kprobe()

In kill_kprobe(), the check whether disarm_kprobe_ftrace() needs to be
called always fails. This is because before that we set the
KPROBE_FLAG_GONE flag for kprobe so that "!kprobe_disabled(p)" is always
false.

The disarm_kprobe_ftrace() call introduced by commit:

  0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler")

to fix the NULL pointer reference problem. When the probe is enabled, if
we do not disarm it, this problem still exists.

Fix it by putting the probe enabled check before setting the
KPROBE_FLAG_GONE flag.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0c76ef3f26d5ef2ac2c21b47e7620cff35809fbb; https://git.kernel.org/stable/c/c909985dd0c0f74b61e3f8f0e04bf8aa9c8b97c7; https://git.kernel.org/stable/c/f20a067f[PII_REDACTED]b4b6a6b665b2088a63824
CVE: CVE-2022-50267
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

mmc: rtsx_pci: fix return value check of mmc_add_host()

mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.

So fix this by checking the return value and calling mmc_free_host() in the
error path, beside, runtime PM also needs be disabled.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0c87db77423a282b3b38b8a6daf057b822680516; https://git.kernel.org/stable/c/30dc645461dfc63e52b3af8ee4a98e17bf14bacf; https://git.kernel.org/stable/c/5cd4e04eccaec140da6fa04db056a76282ee6852
CVE: CVE-2022-50268
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

mmc: moxart: fix return value check of mmc_add_host()

mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.

So fix this by checking the return value and goto error path which will call
mmc_free_host().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0ca18d09c744fb030ae9bc5836c3e357e0237dea; https://git.kernel.org/stable/c/40aa73c70e8a5706f9cbe01409a5e51cc0f1750e; https://git.kernel.org/stable/c/7c3b301ca8b0cab392c71da8fcdfa499074f8e97
CVE: CVE-2022-50269
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/vkms: Fix memory leak in vkms_init()

A memory leak was reported after the vkms module install failed.

unreferenced object 0xffff88810bc28520 (size 16):
  comm "modprobe", pid 9662, jiffies[PII_REDACTED] (age 42.590s)
  hex dump (first 16 bytes):
    01 01 00 64 81 88 ff ff 00 00 dc 0a 81 88 ff ff  ...d............
  backtrace:
    [<00000000e7561ff8>] kmalloc_trace+0x27/0x60
    [<000000000b1954a0>] 0xffffffffc45200a9
    [<00000000abbf1da0>] do_one_initcall+0xd0/0x4f0
    [<[PII_REDACTED]05ee87>] do_init_module+0x1a4/0x680
    [<[PII_REDACTED]8079ad>] load_module+0x6249/0x7110
    [<[PII_REDACTED]7e4696>] __do_sys_finit_module+0x140/0x200
    [<00000000f74b12d2>] do_syscall_64+0x35/0x80
    [<000000008fc6fcde>] entry_SYSCALL_64_after_hwframe+0x46/0xb0

The reason is that the vkms_init() returns without checking the return
value of vkms_create(), and if the vkms_create() failed, the config
allocated at the beginning of vkms_init() is leaked.

 vkms_init()
   config = kmalloc(...) # config allocated
   ...
   return vkms_create() # vkms_create failed and config is leaked

Fix this problem by checking return value of vkms_create() and free the
config if error happened.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/07ab77154d6fd2d67e465ab5ce[PII_REDACTED]0f02; https://git.kernel.org/stable/c/0d0b368b9d104b437e1f4850ae94bdb9a3601e89; https://git.kernel.org/stable/c/bad13de764888b765ceaa4668893b52bd16653cc
CVE: CVE-2022-50270
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix the assign logic of iocb

commit 18ae8d12991b ("f2fs: show more DIO information in tracepoint")
introduces iocb field in 'f2fs_direct_IO_enter' trace event
And it only assigns the pointer and later it accesses its field
in trace print log.

Unable to handle kernel paging request at virtual address ffffffc04cef3d30
Mem abort info:
ESR = 0x96000007
EC = 0x25: DABT (current EL), IL = 32 bits

 pc : trace_raw_output_f2fs_direct_IO_enter+0x54/0xa4
 lr : trace_raw_output_f2fs_direct_IO_enter+0x2c/0xa4
 sp : ffffffc0443cbbd0
 x29: ffffffc0443cbbf0 x28: ffffff8935b120d0 x27: ffffff8935b12108
 x26: ffffff8935b120f0 x25: ffffff8935b12100 x24: ffffff8935b110c0
 x23: ffffff8935b10000 x22: ffffff88859a936c x21: ffffff88859a936c
 x20: ffffff8935b110c0 x19: ffffff8935b10000 x18: ffffffc03b195060
 x17: ffffff8935b11e76 x16:[PII_REDACTED]0000cc x15: ffffffef855c4f2c
 x14: [PII_REDACTED] x13:[PII_REDACTED]00004e x12: ffff0000ffffff00
 x11: ffffffef86c350d0 x10:[PII_REDACTED]0010c0 x9 : 000000000fe0002c
 x8 : ffffffc04cef3d28 x7 : 7f7f7f7f7f7f7f7f x6 : [PII_REDACTED]
 x5 : ffffff8935b11e9a x4 : [PII_REDACTED] x3 : ffff0a00ffffff04
 x2 : [PII_REDACTED] x1 : ffffffef86a0a31f x0 : ffffff8935b10000
 Call trace:
  trace_raw_output_f2fs_direct_IO_enter+0x54/0xa4
  print_trace_fmt+0x9c/0x138
  print_trace_line+0x154/0x254
  tracing_read_pipe+0x21c/0x380
  vfs_read+0x108/0x3ac
  ksys_read+0x7c/0xec
  __arm64_sys_read+0x20/0x30
  invoke_syscall+0x60/0x150
  el0_svc_common.llvm[PII_REDACTED]091755067+0xb8/0xf8
  do_el0_svc+0x28/0xa0

Fix it by copying the required variables for printing and while at
it fix the similar issue at some other places in the same file.
CVSS Score: 7.1 (HIGH)
References: https://git.kernel.org/stable/c/0db18eec0d9a7ee525209e31e3ac2f673545b12f; https://git.kernel.org/stable/c/b4244ca341ea95c52ee8fa93d04f5af3e584dd37; https://git.kernel.org/stable/c/d555aa37566c5c3728f2e52047a9722eae2aed93
CVE: CVE-2022-50271
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

vhost/vsock: Use kvmalloc/kvfree for larger packets.

When copying a large file over sftp over vsock, data size is usually 32kB,
and kmalloc seems to fail to try to allocate 32 32kB regions.

 vhost-5837: page allocation failure: order:4, mode:0x24040c0
 Call Trace:
  [<ffffffffb6a0df64>] dump_stack+0x97/0xdb
  [<ffffffffb68d6aed>] warn_alloc_failed+0x10f/0x138
  [<ffffffffb68d868a>] ? __alloc_pages_direct_compact+0x38/0xc8
  [<ffffffffb664619f>] __alloc_pages_nodemask+0x84c/0x90d
  [<ffffffffb6646e56>] alloc_kmem_pages+0x17/0x19
  [<ffffffffb6653a26>] kmalloc_order_trace+0x2b/0xdb
  [<ffffffffb66682f3>] __kmalloc+0x177/0x1f7
  [<ffffffffb66e0d94>] ? copy_from_iter+0x8d/0x31d
  [<ffffffffc0689ab7>] vhost_vsock_handle_tx_kick+0x1fa/0x301 [vhost_vsock]
  [<ffffffffc06828d9>] vhost_worker+0xf7/0x157 [vhost]
  [<ffffffffb683ddce>] kthread+0xfd/0x105
  [<ffffffffc06827e2>] ? vhost_dev_set_owner+0x22e/0x22e [vhost]
  [<ffffffffb683dcd1>] ? flush_kthread_worker+0xf3/0xf3
  [<ffffffffb6eb332e>] ret_from_fork+0x4e/0x80
  [<ffffffffb683dcd1>] ? flush_kthread_worker+0xf3/0xf3

Work around by doing kvmalloc instead.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0d720c3f0a03e97867deab7e480ba3d3e19837ba; https://git.kernel.org/stable/c/0e3f72931fc47bb81686020cc643cde5d9cd0bb8; https://git.kernel.org/stable/c/36c9f340c60413e28f980c0224c4e9d35851526b
CVE: CVE-2022-50272
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()

Wei Chen reports a kernel bug as blew:

general protection fault, probably for non-canonical address
KASAN: null-ptr-deref in range [0x[PII_REDACTED]000010-0x[PII_REDACTED]000017]
...
Call Trace:
<TASK>
__i2c_transfer+0x77e/0x1930 drivers/i2c/i2c-core-base.c:2109
i2c_transfer+0x1d5/0x3d0 drivers/i2c/i2c-core-base.c:2170
i2cdev_ioctl_rdwr+0x393/0x660 drivers/i2c/i2c-dev.c:297
i2cdev_ioctl+0x75d/0x9f0 drivers/i2c/i2c-dev.c:458
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl+0xfb/0x170 fs/ioctl.c:856
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fd834a8bded

In az6027_i2c_xfer(), if msg[i].addr is 0x99,
a null-ptr-deref will caused when accessing msg[i].buf.
For msg[i].len is 0 and msg[i].buf is null.

Fix this by checking msg[i].len in az6027_i2c_xfer().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0ed554fd769a19ea8464bb83e9ac201002ef74ad; https://git.kernel.org/stable/c/210fcf64be4db82c0e190e74b5111e4eef661a7a; https://git.kernel.org/stable/c/2b6a8a1a[PII_REDACTED]4e7ab06649c804acb4068a
CVE: CVE-2022-50273
Published: 2025-09-15
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to do sanity check on destination blkaddr during recovery

As Wenqing Liu reported in bugzilla:

https://bugzilla.kernel.org/show_bug.cgi?id=216456

loop5: detected capacity change from 0 to 131072
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): Bitmap was wrongly set, blk:5634
------------[ cut here ]------------
WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198
RIP: 0010:update_sit_entry+0xa55/0x10b0 [f2fs]
Call Trace:
 <TASK>
 f2fs_do_replace_block+0xa98/0x1890 [f2fs]
 f2fs_replace_block+0xeb/0x180 [f2fs]
 recover_data+0x1a69/0x6ae0 [f2fs]
 f2fs_recover_fsync_data+0x120d/0x1fc0 [f2fs]
 f2fs_fill_super+0x4665/0x61e0 [f2fs]
 mount_bdev+0x2cf/0x3b0
 legacy_get_tree+0xed/0x1d0
 vfs_get_tree+0x81/0x2b0
 path_mount+0x47e/0x19d0
 do_mount+0xce/0xf0
 __x64_sys_mount+0x12c/0x1a0
 do_syscall_64+0x38/0x90
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

If we enable CONFIG_F2FS_CHECK_FS config, it will trigger a kernel panic
instead of warning.

The root cause is: in fuzzed image, SIT table is inconsistent with inode
mapping table, result in triggering such warning during SIT table update.

This patch introduces a new flag DATA_GENERIC_ENHANCE_UPDATE, w/ this
flag, data block recovery flow can check destination blkaddr's validation
in SIT table, and skip f2fs_replace_block() to avoid inconsistent status.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0ef4ca04a3f9223ff8bc440041c524b2123e09a3; https://git.kernel.org/stable/c/3a4d24d746866dd45d970bd565ff3886e839366a; https://git.kernel.org/stable/c/68b1e607559d3dc85f94b0d738d7c4e8029b0cfa