Page 128 of 4548 results (0.007 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: btrfs: do not clear page dirty inside extent_write_locked_range() [BUG] For subpage + zoned case, the following workload can lead to rsv data leak at unmount time: # mkfs.btrfs -f -s 4k $dev # mount $dev $mnt # fsstress -w -n 8 -d $mnt -s 1709539240 0/0: fiemap - no filename 0/1: copyrange read - no filename 0/2: write - no filename 0/3: rename - no source filename 0/4: creat f0 x:0 0 0 0/4: creat add id=0,parent=-1 0/5: writev f0[259 1 0 0 0 0] [778052,113,965] 0 0/6: ioctl(FIEMAP) f0[259 1 0 0 224 887097] [1294220,2291618343991484791,0x10000] -1 0/7: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 224 887097] return 25, fallback to stat() 0/7: dwrite f0[259 1 0 0 224 887097] [696320,102400] 0 # umount $mnt The dmesg includes the following rsv leak detection warning (all call trace skipped): ------------[ cut here ]------------ WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8653 btrfs_destroy_inode+0x1e0/0x200 [btrfs] ---[ end trace 0000000000000000 ]--- ------------[ cut here ]------------ WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8654 btrfs_destroy_inode+0x1a8/0x200 [btrfs] ---[ end trace 0000000000000000 ]--- ------------[ cut here ]------------ WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8660 btrfs_destroy_inode+0x1a0/0x200 [btrfs] ---[ end trace 0000000000000000 ]--- BTRFS info (device sda): last unmount of filesystem 1b4abba9-de34-4f07-9e7f-157cf12a18d6 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs] ---[ end trace 0000000000000000 ]--- BTRFS info (device sda): space_info DATA has 268218368 free, is not full BTRFS info (device sda): space_info total=268435456, used=204800, pinned=0, reserved=0, may_use=12288, readonly=0 zone_unusable=0 BTRFS info (device sda): global_block_rsv: size 0 reserved 0 BTRFS info (device sda): trans_block_rsv: size 0 reserved 0 BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0 BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0 BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs] ---[ end trace 0000000000000000 ]--- BTRFS info (device sda): space_info METADATA has 267796480 free, is not full BTRFS info (device sda): space_info total=268435456, used=131072, pinned=0, reserved=0, may_use=262144, readonly=0 zone_unusable=245760 BTRFS info (device sda): global_block_rsv: size 0 reserved 0 BTRFS info (device sda): trans_block_rsv: size 0 reserved 0 BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0 BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0 BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0 Above $dev is a tcmu-runner emulated zoned HDD, which has a max zone append size of 64K, and the system has 64K page size. [CAUSE] I have added several trace_printk() to show the events (header skipped): > btrfs_dirty_pages: r/i=5/259 dirty start=774144 len=114688 > btrfs_dirty_pages: r/i=5/259 dirty part of page=720896 off_in_page=53248 len_in_page=12288 > btrfs_dirty_pages: r/i=5/259 dirty part of page=786432 off_in_page=0 len_in_page=65536 > btrfs_dirty_pages: r/i=5/259 dirty part of page=851968 off_in_page=0 len_in_page=36864 The above lines show our buffered write has dirtied 3 pages of inode 259 of root 5: 704K 768K 832K 896K I |////I/////////////////I///////////| I 756K 868K |///| is the dirtied range using subpage bitmaps. and 'I' is the page boundary. Meanwhile all three pages (704K, 768K, 832K) have their PageDirty flag set. > btrfs_direct_write: r/i=5/259 start dio filepos=696320 len=102400 Then direct IO writ ---truncated--- • https://git.kernel.org/stable/c/ba4dedb71356638d8284e34724daca944be70368 https://git.kernel.org/stable/c/d3b403209f767e5857c1b9fda66726e6e6ffc99f https://git.kernel.org/stable/c/97713b1a2ced1e4a2a6c40045903797ebd44d7e0 •

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

In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register() bcm_sf2_mdio_register() calls of_phy_find_device() and then phy_device_remove() in a loop to remove existing PHY devices. of_phy_find_device() eventually calls bus_find_device(), which calls get_device() on the returned struct device * to increment the refcount. The current implementation does not decrement the refcount, which causes memory leak. This commit adds the missing phy_device_free() call to decrement the refcount via put_device() to balance the refcount. • https://git.kernel.org/stable/c/771089c2a485958e423f305e974303760167b45c https://git.kernel.org/stable/c/b7b8d9f5e679af60c94251fd6728dde34be69a71 https://git.kernel.org/stable/c/c05516c072903f6fb9134b8e7e1ad4bffcdc4819 https://git.kernel.org/stable/c/7feef10768ea71d468d9bbc1e0d14c461876768c https://git.kernel.org/stable/c/a7d2808d67570e6acae45c2a96e0d59986888e4c https://git.kernel.org/stable/c/f3d5efe18a11f94150fee8b3fda9d62079af640a https://git.kernel.org/stable/c/e3862093ee93fcfbdadcb7957f5f8974fffa806a •

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

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: SHAMPO, Fix invalid WQ linked list unlink When all the strides in a WQE have been consumed, the WQE is unlinked from the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible to receive CQEs with 0 consumed strides for the same WQE even after the WQE is fully consumed and unlinked. This triggers an additional unlink for the same wqe which corrupts the linked list. Fix this scenario by accepting 0 sized consumed strides without unlinking the WQE again. • https://git.kernel.org/stable/c/7b379353e9144e1f7460ff15f39862012c9d0d78 https://git.kernel.org/stable/c/650e24748e1e0a7ff91d5c72b72a2f2a452b5b76 https://git.kernel.org/stable/c/50d8009a0ac02c3311b23a0066511f8337bd88d9 https://git.kernel.org/stable/c/fba8334721e266f92079632598e46e5f89082f30 https://access.redhat.com/security/cve/CVE-2024-44970 https://bugzilla.redhat.com/show_bug.cgi?id=2309801 • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •

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

In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Prevent release of buffer in I/O When a task waiting for completion of a Store Data operation is interrupted, an attempt is made to halt this operation. If this attempt fails due to a hardware or firmware problem, there is a chance that the SCLP facility might store data into buffers referenced by the original operation at a later time. Handle this situation by not releasing the referenced data buffers if the halt attempt fails. For current use cases, this might result in a leak of few pages of memory in case of a rare hardware/firmware malfunction. • https://git.kernel.org/stable/c/7a7e60ed23d471a07dbbe72565d2992ee8244bbe https://git.kernel.org/stable/c/1ec5ea9e25f582fd6999393e2f2c3bf56f234e05 https://git.kernel.org/stable/c/a3e52a4c22c846858a6875e1c280030a3849e148 https://git.kernel.org/stable/c/a88a49473c94ccfd8dce1e766aacf3c627278463 https://git.kernel.org/stable/c/46f67233b011385d53cf14d272431755de3a7c79 https://git.kernel.org/stable/c/1e8b7fb427af6b2ddd54eff66a6b428a81c96633 https://git.kernel.org/stable/c/2429ea3b4330e3653b72b210a0d5f2a717359506 https://git.kernel.org/stable/c/bf365071ea92b9579d5a272679b74052a •

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

In the Linux kernel, the following vulnerability has been resolved: drm/mgag200: Bind I2C lifetime to DRM device Managed cleanup with devm_add_action_or_reset() will release the I2C adapter when the underlying Linux device goes away. But the connector still refers to it, so this cleanup leaves behind a stale pointer in struct drm_connector.ddc. Bind the lifetime of the I2C adapter to the connector's lifetime by using DRM's managed release. When the DRM device goes away (after the Linux device) DRM will first clean up the connector and then clean up the I2C adapter. • https://git.kernel.org/stable/c/b279df242972ae816a75cf1cc732af836f999100 https://git.kernel.org/stable/c/55a6916db77102765b22855d3a0add4751988b7c https://git.kernel.org/stable/c/81d34df843620e902dd04aa9205c875833d61c17 https://git.kernel.org/stable/c/9d96b91e03cba9dfcb4ac370c93af4dbc47d5191 https://git.kernel.org/stable/c/eb1ae34e48a09b7a1179c579aed042b032e408f4 •