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-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 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56569 – ftrace: Fix regression with module command in stack_trace_filter
https://notcve.org/view.php?id=CVE-2024-56569
In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix regression with module command in stack_trace_filter When executing the following command: # echo "write*:mod:ext3" > /sys/kernel/tracing/stack_trace_filter The current mod command causes a null pointer dereference. While commit 0f17976568b3f ("ftrace: Fix regression with module command in stack_trace_filter") has addressed part of the issue, it left a corner case unhandled, which still results in a kernel crash. • https://git.kernel.org/stable/c/04ec7bb642b77374b53731b795b5654b5aff1c00 https://git.kernel.org/stable/c/43ca32ce12888fb0eeb2d74dfc558dea60d3473e https://git.kernel.org/stable/c/5dabb7af57bc72308a6e2e81a5dd756eef283803 https://git.kernel.org/stable/c/885109aa0c70639527dd6a65c82e63c9ac055e3d https://git.kernel.org/stable/c/7ae27880de3482e063fcc1f72d9a298d0d391407 https://git.kernel.org/stable/c/8a92dc4df89c50bdb26667419ea70e0abbce456e https://git.kernel.org/stable/c/19cacabdd5a8487ae566cbecb4d03bcb038a067e https://git.kernel.org/stable/c/45af52e7d3b8560f21d139b3759735eea •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-56568 – iommu/arm-smmu: Defer probe of clients after smmu device bound
https://notcve.org/view.php?id=CVE-2024-56568
In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu: Defer probe of clients after smmu device bound Null pointer dereference occurs due to a race between smmu driver probe and client driver probe, when of_dma_configure() for client is called after the iommu_device_register() for smmu driver probe has executed but before the driver_bound() for smmu driver has been called. Following is how the race occurs: T1:Smmu device probe T2: Client device probe really_probe() arm_smmu_device_probe() iommu_device_register() really_probe() platform_dma_configure() of_dma_configure() of_dma_configure_id() of_iommu_configure() iommu_probe_device() iommu_init_device() arm_smmu_probe_device() arm_smmu_get_by_fwnode() driver_find_device_by_fwnode() driver_find_device() next_device() klist_next() /* null ptr assigned to smmu */ /* null ptr dereference while smmu->streamid_mask */ driver_bound() klist_add_tail() When this null smmu pointer is dereferenced later in arm_smmu_probe_device, the device crashes. Fix this by deferring the probe of the client device until the smmu device has bound to the arm smmu driver. [will: Add comment] • https://git.kernel.org/stable/c/021bb8420d44cf56102d44fca9af628625e75482 https://git.kernel.org/stable/c/c2527d07c7e9cda2c6165d5edccf74752baac1b0 https://git.kernel.org/stable/c/dc02407ea952e20c544a078a6be2e6f008327973 https://git.kernel.org/stable/c/f8f794f387ad21c4696e5cd0626cb6f8a5f6aea5 https://git.kernel.org/stable/c/4a9485918a042e3114890dfbe19839a1897f8b2c https://git.kernel.org/stable/c/5018696b19bc6c021e934a8a59f4b1dd8c0ac9f8 https://git.kernel.org/stable/c/229e6ee43d2a160a1592b83aad620d6027084aad •