Page 16 of 3679 results (0.006 seconds)

CVSS: -EPSS: 0%CPEs: 7EXPL: 0

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: 0

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: 0

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: 0

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: 0

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 •