CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56576 – media: i2c: tc358743: Fix crash in the probe error path when using polling
https://notcve.org/view.php?id=CVE-2024-56576
In the Linux kernel, the following vulnerability has been resolved: media: i2c: tc358743: Fix crash in the probe error path when using polling If an error occurs in the probe() function, we should remove the polling timer that was alarmed earlier, otherwise the timer is called with arguments that are already freed, which results in a crash. ------------[ cut here ]------------ WARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268 Modules linked in: CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) pstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __run_timers+0x244/0x268 lr : __run_timers+0x1d4/0x268 sp : ffffff80eff2baf0 x29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00 x26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00 x23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000 x20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffff x17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003e x14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000 x11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009 x8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480 x5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240 x2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0 Call trace: __run_timers+0x244/0x268 timer_expire_remote+0x50/0x68 tmigr_handle_remote+0x388/0x39c run_timer_softirq+0x38/0x44 handle_softirqs+0x138/0x298 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x24/0x4c do_softirq_own_stack+0x1c/0x2c irq_exit_rcu+0x9c/0xcc el1_interrupt+0x48/0xc0 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x7c/0x80 default_idle_call+0x34/0x68 do_idle+0x23c/0x294 cpu_startup_entry+0x38/0x3c secondary_start_kernel+0x128/0x160 __secondary_switched+0xb8/0xbc ---[ end trace 0000000000000000 ]--- • https://git.kernel.org/stable/c/4e66a52a2e4c832dfa35a39204d0f7ce717d4a4a https://git.kernel.org/stable/c/13193a97ddd5a6a5b11408ddbc1ae85588b1860c https://git.kernel.org/stable/c/5c9ab34c87af718bdbf9faa2b1a6ba41d15380ea https://git.kernel.org/stable/c/815d14147068347e88c258233eb951b41b2792a6 https://git.kernel.org/stable/c/34a3466a92f50c51d984f0ec2e96864886d460eb https://git.kernel.org/stable/c/b59ab89bc83f7bff67f78c6caf484a84a6dd30f7 https://git.kernel.org/stable/c/1def915b1564f4375330bd113ea1d768a569cfd8 https://git.kernel.org/stable/c/869f38ae07f7df829da4951c3d1f7a2be •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56574 – media: ts2020: fix null-ptr-deref in ts2020_probe()
https://notcve.org/view.php?id=CVE-2024-56574
In the Linux kernel, the following vulnerability has been resolved: media: ts2020: fix null-ptr-deref in ts2020_probe() KASAN reported a null-ptr-deref issue when executing the following command: # echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020] RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809 RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010 RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6 R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790 R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001 FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ts2020_probe+0xad/0xe10 [ts2020] i2c_device_probe+0x421/0xb40 really_probe+0x266/0x850 ... The cause of the problem is that when using sysfs to dynamically register an i2c device, there is no platform data, but the probe process of ts2020 needs to use platform data, resulting in a null pointer being accessed. Solve this problem by adding checks to platform data. • https://git.kernel.org/stable/c/dc245a5f9b5163511e0c164c8aa47848f07b75a9 https://git.kernel.org/stable/c/ced1c04e82e3ecc246b921b9733f0df0866aa50d https://git.kernel.org/stable/c/5a53f97cd5977911850b695add057f9965c1a2d6 https://git.kernel.org/stable/c/b6208d1567f929105011bcdfd738f59a6bdc1088 https://git.kernel.org/stable/c/dc03866b5f4aa2668946f8384a1e5286ae53bbaa https://git.kernel.org/stable/c/a2ed3b780f34e4a6403064208bc2c99d1ed85026 https://git.kernel.org/stable/c/901070571bc191d1d8d7a1379bc5ba9446200999 https://git.kernel.org/stable/c/4a058b34b52ed3feb1f3ff6fd26aefeee •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56572 – media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal()
https://notcve.org/view.php?id=CVE-2024-56572
In the Linux kernel, the following vulnerability has been resolved: media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal() The buffer in the loop should be released under the exception path, otherwise there may be a memory leak here. To mitigate this, free the buffer when allegro_alloc_buffer fails. • https://git.kernel.org/stable/c/f20387dfd065693ba7ea2788a2f893bf653c9cb8 https://git.kernel.org/stable/c/cf642904be39ae0d441dbdfa8f485e0a46260be4 https://git.kernel.org/stable/c/74a65313578b35e1239966adfa7ac2bdd60caf00 https://git.kernel.org/stable/c/64f72a738864b506ab50b4a6cb3ce3c3e04b71af https://git.kernel.org/stable/c/17e5613666209be4e5be1f1894f1a6014a8a0658 https://git.kernel.org/stable/c/6712a28a4f923ffdf51cff267ad05a634ee1babc https://git.kernel.org/stable/c/891b5790bee8fc6ddba17874dd87a646128d0b99 https://git.kernel.org/stable/c/0f514068fbc5d4d189c817adc7c4e32cf •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-56571 – media: uvcvideo: Require entities to have a non-zero unique ID
https://notcve.org/view.php?id=CVE-2024-56571
In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Require entities to have a non-zero unique ID Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID. ``` Each Unit and Terminal within the video function is assigned a unique identification number, the Unit ID (UID) or Terminal ID (TID), contained in the bUnitID or bTerminalID field of the descriptor. The value 0x00 is reserved for undefined ID, ``` So, deny allocating an entity with ID 0 or an ID that belongs to a unit that is already added to the list of entities. This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings. In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid. Here is a sample stack trace for one of those cases. [ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? • https://git.kernel.org/stable/c/a3fbc2e6bb05a3b1ea341cd29dea09b4a033727b https://git.kernel.org/stable/c/bde4e7c1527151b596089b3f984818ab537eeb7f https://git.kernel.org/stable/c/72ed66623953106d15825513c82533a03ba29ecd https://git.kernel.org/stable/c/19464d73225224dca31e2fd6e7d6418facf5facb https://git.kernel.org/stable/c/b11813bc2f4eee92695075148c9ba996f54feeba https://git.kernel.org/stable/c/4f74bd307f078c0605b9f6f1edb8337dee35fa2e https://git.kernel.org/stable/c/3dd075fe8ebbc6fcbf998f81a75b8c4b159a6195 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56570 – ovl: Filter invalid inodes with missing lookup function
https://notcve.org/view.php?id=CVE-2024-56570
In the Linux kernel, the following vulnerability has been resolved: ovl: Filter invalid inodes with missing lookup function Add a check to the ovl_dentry_weird() function to prevent the processing of directory inodes that lack the lookup function. This is important because such inodes can cause errors in overlayfs when passed to the lowerstack. • https://git.kernel.org/stable/c/f9248e2f73fb4afe08324485e98c815ac084d166 https://git.kernel.org/stable/c/5f86e79c0b2287ffdabe6c1b305a36c4e0f40fe3 https://git.kernel.org/stable/c/749eac5a6687ec99116e0691d0d71225254654e3 https://git.kernel.org/stable/c/ff43d008bbf9b27ada434d6455f039a5ef6cee53 https://git.kernel.org/stable/c/065bf5dd21639f80e68450de16bda829784dbb8c https://git.kernel.org/stable/c/72014e7745cc8250bb8f27bd78694dfd3f1b5773 https://git.kernel.org/stable/c/c8b359dddb418c60df1a69beea01d1b3322bfe83 •