Linux Kernel up to 6.2.2 media ov772x_probe memory leak

Summaryinfo

A vulnerability was found in Linux Kernel up to 6.2.2. It has been classified as critical. Affected by this vulnerability is the function ov772x_probe of the component media. The manipulation leads to memory leak. This vulnerability is uniquely identified as CVE-2023-53637. No exploit exists. Upgrading the affected component is recommended.

Detailsinfo

A vulnerability was found in Linux Kernel up to 6.2.2. It has been rated as critical. This issue affects the function ov772x_probe of the component media. The manipulation with an unknown input leads to a memory leak vulnerability. Using CWE to declare the problem leads to CWE-401. The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory. Impacted is availability. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: media: i2c: ov772x: Fix memleak in ov772x_probe() A memory leak was reported when testing ov772x with bpf mock device: AssertionError: unreferenced object 0xffff888109afa7a8 (size 8): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 8 bytes): 80 22 88 15 81 88 ff ff ."...... backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<00000000faf48134>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev] [<00000000da376937>] ov772x_probe+0x1c3/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110 [<00000000a9f2159d>] of_i2c_notify+0x100/0x160 unreferenced object 0xffff888119825c00 (size 256): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 32 bytes): 00 b4 a5 17 81 88 ff ff 00 5e 82 19 81 88 ff ff .........^...... 10 5c 82 19 81 88 ff ff 10 5c 82 19 81 88 ff ff .\.......\...... backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<0000000073d88e0b>] v4l2_ctrl_new.cold+0x19b/0x86f [videodev] [<00000000b1f576fb>] v4l2_ctrl_new_std+0x16f/0x210 [videodev] [<00000000caf7ac99>] ov772x_probe+0x1fa/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110 The reason is that if priv->hdl.error is set, ov772x_probe() jumps to the error_mutex_destroy without doing v4l2_ctrl_handler_free(), and all resources allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() are leaked.

The advisory is shared at git.kernel.org. The identification of this vulnerability is CVE-2023-53637 since 10/07/2025. The exploitation is known to be difficult. Technical details are known, but no exploit is available.

Upgrading to version 4.19.276, 5.4.235, 5.10.173, 5.15.99, 6.1.16 or 6.2.3 eliminates this vulnerability. Applying the patch cc3b6011d7a9f149489eb9420c6305a779162c57/448ce1cd50387b1345ec14eb191ef05f7afc2a26/dfaafeb8e9537969e8dba75491f732478c7fa9d6/1da495101ef7507eb4f4b1dbec2874d740eff251/ac93f8ac66e60227bed42d5a023f0e6c15b52c0a/c86d760c1c6855a6131e78d0ddacc48c79324ac3/7485edb2b6ca5960205c0a49bedfd09bba30e521 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the vulnerability database at CERT Bund (WID-SEC-2025-2229). If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Affected

• Amazon Linux 2
• Red Hat Enterprise Linux
• SUSE Linux
• Oracle Linux
• RESF Rocky Linux
• Open Source Linux Kernel
• IBM QRadar SIEM
• Dell NetWorker

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 4.19.275
• 5.4.234
• 5.10.172
• 5.15.0
• 5.15.1
• 5.15.2
• 5.15.3
• 5.15.4
• 5.15.5
• 5.15.6
• 5.15.7
• 5.15.8
• 5.15.9
• 5.15.10
• 5.15.11
• 5.15.12
• 5.15.13
• 5.15.14
• 5.15.15
• 5.15.16
• 5.15.17
• 5.15.18
• 5.15.19
• 5.15.20
• 5.15.21
• 5.15.22
• 5.15.23
• 5.15.24
• 5.15.25
• 5.15.26
• 5.15.27
• 5.15.28
• 5.15.29
• 5.15.30
• 5.15.31
• 5.15.32
• 5.15.33
• 5.15.34
• 5.15.35
• 5.15.36
• 5.15.37
• 5.15.38
• 5.15.39
• 5.15.40
• 5.15.41
• 5.15.42
• 5.15.43
• 5.15.44
• 5.15.45
• 5.15.46
• 5.15.47
• 5.15.48
• 5.15.49
• 5.15.50
• 5.15.51
• 5.15.52
• 5.15.53
• 5.15.54
• 5.15.55
• 5.15.56
• 5.15.57
• 5.15.58
• 5.15.59
• 5.15.60
• 5.15.61
• 5.15.62
• 5.15.63
• 5.15.64
• 5.15.65
• 5.15.66
• 5.15.67
• 5.15.68
• 5.15.69
• 5.15.70
• 5.15.71
• 5.15.72
• 5.15.73
• 5.15.74
• 5.15.75
• 5.15.76
• 5.15.77
• 5.15.78
• 5.15.79
• 5.15.80
• 5.15.81
• 5.15.82
• 5.15.83
• 5.15.84
• 5.15.85
• 5.15.86
• 5.15.87
• 5.15.88
• 5.15.89
• 5.15.90
• 5.15.91
• 5.15.92
• 5.15.93
• 5.15.94
• 5.15.95
• 5.15.96
• 5.15.97
• 5.15.98
• 6.1.0
• 6.1.1
• 6.1.2
• 6.1.3
• 6.1.4
• 6.1.5
• 6.1.6
• 6.1.7
• 6.1.8
• 6.1.9
• 6.1.10
• 6.1.11
• 6.1.12
• 6.1.13
• 6.1.14
• 6.1.15
• 6.2.0
• 6.2.1
• 6.2.2

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion