Page 32 of 5520 results (0.040 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the "localio" optimisation for loopback NFS mounts. • https://git.kernel.org/stable/c/c2a9737f45e27d8263ff9643f994bda9bac0b944 https://git.kernel.org/stable/c/272830350bb1bb5bb39395966ea63b9864b135d1 https://git.kernel.org/stable/c/fbc7b803831e5c8a42c1f3427a17e55a814d6b3c https://git.kernel.org/stable/c/3d549dcfbbb0ecdaa571431a27ee5da9f2466716 https://git.kernel.org/stable/c/26530b757c81f1389fb33ae0357500150933161b https://git.kernel.org/stable/c/a2746ab3bbc9c6408da5cd072653ec8c24749235 https://git.kernel.org/stable/c/6450e73f4c86d481ac2e22e1bc848d346e140826 https://git.kernel.org/stable/c/ace149e0830c380ddfce7e466fe860ca5 •

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

In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. • https://git.kernel.org/stable/c/d64696905554e919321e31afc210606653b8f6a4 https://git.kernel.org/stable/c/012f4d5d25e9ef92ee129bd5aa7aa60f692681e1 https://git.kernel.org/stable/c/4877d9b2a2ebad3ae240127aaa4cb8258b145cf7 https://git.kernel.org/stable/c/0208ea17a1e4456fbfe555f13ae5c28f3d671e40 https://git.kernel.org/stable/c/9e05e5c7ee8758141d2db7e8fea2cab34500c6ed •

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

In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation. • https://git.kernel.org/stable/c/9294a037c01564786abb15436529fae3863268a2 https://git.kernel.org/stable/c/2d339a1f0f16ff5dea58e612ff336f0be0d041e9 https://git.kernel.org/stable/c/4401e9d10ab0281a520b9f8c220f30f60b5c248f •

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

In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY on exit") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit(). • https://git.kernel.org/stable/c/6ed05c68cbcae42cd52b8e53b66952bfa9c002ce https://git.kernel.org/stable/c/583a4219841d00e96b5de55be160aa7eb7721a4d https://git.kernel.org/stable/c/b4ecc15d6f5a13c0bbe2777438e87e321f83faaa https://git.kernel.org/stable/c/a2259ebaa933331c53904caf792b619ec42f0da5 https://git.kernel.org/stable/c/721ddad945596220c123eb6f7126729fe277ee4f https://git.kernel.org/stable/c/4aa77d5ea9944468e16c3eed15e858fd5de44de1 https://git.kernel.org/stable/c/6e2848d1c8c0139161e69ac0a94133e90e9988e8 https://git.kernel.org/stable/c/63559ba8077cbadae1c92a65b73ea522b •

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

In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The "*cmd" variable can be controlled by the user via debugfs. That means "new_cam" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control() • https://git.kernel.org/stable/c/170a6726d0e266f2c8f306e3d61715c32f4ee41e https://git.kernel.org/stable/c/d76923164705821aa1b01b8d9d1741f20c654ab4 https://git.kernel.org/stable/c/8f47984b35f3be0cfc652c2ca358d5768ea3456b https://git.kernel.org/stable/c/604314ecd682913925980dc955caea2d036eab5f https://git.kernel.org/stable/c/69e19774f15e12dda6c6c58001d059e30895009b https://git.kernel.org/stable/c/3a2ba841659a0f15102585120dea75d8d5209616 https://git.kernel.org/stable/c/7dd08a0b4193087976db6b3ee7807de7e8316f96 •