Page 5 of 4594 results (0.008 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885_vdev_init() return cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL. • https://git.kernel.org/stable/c/8e31b096e2e1949bc8f0be019c9ae70d414404c6 https://git.kernel.org/stable/c/199a42fc4c45e8b7f19efeb15dbc36889a599ac2 https://git.kernel.org/stable/c/e7385510e2550a9f8b6f3d5f33c5b894ab9ba976 https://git.kernel.org/stable/c/a5f1d30c51c485cec7a7de60205667c3ff86c303 https://git.kernel.org/stable/c/06ee04a907d64ee3910fecedd05d7f1be4b1b70e https://git.kernel.org/stable/c/b1397fb4a779fca560c43d2acf6702d41b4a495b https://git.kernel.org/stable/c/15126b916e39b0cb67026b0af3c014bfeb1f76b3 •

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

In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit() Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: <TASK> dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80 Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item in btrfs_run_qgroups() later outside of the spinlock context. • https://git.kernel.org/stable/c/89840b12c8fad7200eb6478525c13261512c01be https://git.kernel.org/stable/c/3c98e91be6aea4c7acf09da6eb0c107ea9186bb5 https://git.kernel.org/stable/c/f4b930a1602b05e77fee31f9616599b25e910a86 https://git.kernel.org/stable/c/8eb912af525042a7365295eb62f6d5270c2a6462 https://git.kernel.org/stable/c/01d7c41eac9129fba80d8aed0060caab4a7dbe09 https://git.kernel.org/stable/c/044da1a371a0da579e805e89c96865f62d8f6f69 https://git.kernel.org/stable/c/588ae4fdd8b11788a797776b10d6c44ae12bc133 https://git.kernel.org/stable/c/f7e942b5bb35d8e3af54053d19a6bf041 •

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

In the Linux kernel, the following vulnerability has been resolved: iio: health: afe4404: Fix oob read in afe4404_[read|write]_raw KASAN report out-of-bounds read as follows: BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380 Read of size 4 at addr ffffffffc00e4658 by task cat/278 Call Trace: afe4404_read_raw iio_read_channel_info dev_attr_show The buggy address belongs to the variable: afe4404_channel_leds+0x18/0xffffffffffffe9c0 This issue can be reproduce by singe command: $ cat /sys/bus/i2c/devices/0-0058/iio\:device0/in_intensity6_raw The array size of afe4404_channel_leds and afe4404_channel_offdacs are less than channels, so access with chan->address cause OOB read in afe4404_[read|write]_raw. Fix it by moving access before use them. • https://git.kernel.org/stable/c/b36e8257641a043764c62240316610c81e36376c https://git.kernel.org/stable/c/68de7da092f38395dde523f2e5db26eba6c23e28 https://git.kernel.org/stable/c/113c08030a89aaf406f8a1d4549d758a67c2afba https://git.kernel.org/stable/c/f5575041ec15310bdc50c42b8b22118cc900226e https://git.kernel.org/stable/c/3f566b626029ca8598d48e5074e56bb37399ca1b https://git.kernel.org/stable/c/5eb114f55b37dbc0487aa9c1913b81bb7837f1c4 https://git.kernel.org/stable/c/f7419fc42afc035f6b29ce713e17dcd2000c833f https://git.kernel.org/stable/c/d45d9f45e7b1365fd0d9bf14680d6d508 •

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

In the Linux kernel, the following vulnerability has been resolved: iio: health: afe4403: Fix oob read in afe4403_read_raw KASAN report out-of-bounds read as follows: BUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0 Read of size 4 at addr ffffffffc02ac638 by task cat/279 Call Trace: afe4403_read_raw iio_read_channel_info dev_attr_show The buggy address belongs to the variable: afe4403_channel_leds+0x18/0xffffffffffffe9e0 This issue can be reproduced by singe command: $ cat /sys/bus/spi/devices/spi0.0/iio\:device0/in_intensity6_raw The array size of afe4403_channel_leds is less than channels, so access with chan->address cause OOB read in afe4403_read_raw. Fix it by moving access before use it. • https://git.kernel.org/stable/c/b36e8257641a043764c62240316610c81e36376c https://git.kernel.org/stable/c/98afcb5f3be645d330c74c5194ba0d80e26f95e0 https://git.kernel.org/stable/c/c9268df36818ee4eaaaeadc80009b442a5ca69c9 https://git.kernel.org/stable/c/726fa3e4ab97dcff1c745bdc4fb137366cb8d3df https://git.kernel.org/stable/c/2d6a437064ffbe685c67ddb16dfc0946074c6c3f https://git.kernel.org/stable/c/b1756af172fb80a3edc143772d49e166ec691b6c https://git.kernel.org/stable/c/e7e76a77aabef8989cbc0a8417af1aa040620867 https://git.kernel.org/stable/c/06c6ce21cec77dfa860d57e7a006000a5 •

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

In the Linux kernel, the following vulnerability has been resolved: libbpf: Handle size overflow for ringbuf mmap The maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entries will overflow u32 when mapping producer page and data pages. Only casting max_entries to size_t is not enough, because for 32-bits application on 64-bits kernel the size of read-only mmap region also could overflow size_t. So fixing it by casting the size of read-only mmap region into a __u64 and checking whether or not there will be overflow during mmap. • https://git.kernel.org/stable/c/bf99c936f9478a05d51e9f101f90de70bee9a89c https://git.kernel.org/stable/c/8a549ab6724520aa3c07f47e0eba820293551490 https://git.kernel.org/stable/c/0140e079a42064680394fff1199a7b5483688dec https://git.kernel.org/stable/c/535a25ab4f9a45f74ba38ab71de95e97474922ed https://git.kernel.org/stable/c/927cbb478adf917e0a142b94baa37f06279cc466 •