CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-42281 – bpf: Fix a segment issue when downgrading gso_size
https://notcve.org/view.php?id=CVE-2024-42281
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a segment issue when downgrading gso_size Linearize the skb when downgrading gso_size because it may trigger a BUG_ON() later when the skb is segmented as described in [1,2]. • https://git.kernel.org/stable/c/2be7e212d5419a400d051c84ca9fdd083e5aacac https://git.kernel.org/stable/c/a689f5eb13a90f892a088865478b3cd39f53d5dc https://git.kernel.org/stable/c/dda518dea60d556a2d171c0122ca7d9fdb7d473a https://git.kernel.org/stable/c/f6bb8c90cab97a3e03f8d30e3069efe6a742e0be https://git.kernel.org/stable/c/11ec79f5c7f74261874744039bc1551023edd6b2 https://git.kernel.org/stable/c/c3496314c53e7e82ddb544c825defc3e8c0e45cf https://git.kernel.org/stable/c/ec4eea14d75f7b0491194dd413f540dd19b8c733 https://git.kernel.org/stable/c/fa5ef655615a01533035c6139248c5b33 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42280 – mISDN: Fix a use after free in hfcmulti_tx()
https://notcve.org/view.php?id=CVE-2024-42280
In the Linux kernel, the following vulnerability has been resolved: mISDN: Fix a use after free in hfcmulti_tx() Don't dereference *sp after calling dev_kfree_skb(*sp). • https://git.kernel.org/stable/c/af69fb3a8ffa37e986db00ed93099dc44babeef4 https://git.kernel.org/stable/c/70db2c84631f50e02e6b32b543700699dd395803 https://git.kernel.org/stable/c/d3e4d4a98c5629ccdcb762a0ff6c82ba9738a0c3 https://git.kernel.org/stable/c/9460ac3dd1ae033bc2b021a458fb535a0c36ddb2 https://git.kernel.org/stable/c/8f4030277dfb9dbe04fd78566b19931097c9d629 https://git.kernel.org/stable/c/4d8b642985ae24f4b3656438eb8489834a17bb80 https://git.kernel.org/stable/c/ddc79556641ee070d36be0de4a1f0a16a71f1fc7 https://git.kernel.org/stable/c/7e4a539bca7d8d20f2c5d93c18cce8ef7 •
CVSS: 6.3EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42271 – net/iucv: fix use after free in iucv_sock_close()
https://notcve.org/view.php?id=CVE-2024-42271
In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use after free in iucv_sock_close() iucv_sever_path() is called from process context and from bh context. iucv->path is used as indicator whether somebody else is taking care of severing the path (or it is already removed / never existed). This needs to be done with atomic compare and swap, otherwise there is a small window where iucv_sock_close() will try to work with a path that has already been severed and freed by iucv_callback_connrej() called by iucv_tasklet_fn(). Example: [452744.123844] Call Trace: [452744.123845] ([<0000001e87f03880>] 0x1e87f03880) [452744.123966] [<00000000d593001e>] iucv_path_sever+0x96/0x138 [452744.124330] [<000003ff801ddbca>] iucv_sever_path+0xc2/0xd0 [af_iucv] [452744.124336] [<000003ff801e01b6>] iucv_sock_close+0xa6/0x310 [af_iucv] [452744.124341] [<000003ff801e08cc>] iucv_sock_release+0x3c/0xd0 [af_iucv] [452744.124345] [<00000000d574794e>] __sock_release+0x5e/0xe8 [452744.124815] [<00000000d5747a0c>] sock_close+0x34/0x48 [452744.124820] [<00000000d5421642>] __fput+0xba/0x268 [452744.124826] [<00000000d51b382c>] task_work_run+0xbc/0xf0 [452744.124832] [<00000000d5145710>] do_notify_resume+0x88/0x90 [452744.124841] [<00000000d5978096>] system_call+0xe2/0x2c8 [452744.125319] Last Breaking-Event-Address: [452744.125321] [<00000000d5930018>] iucv_path_sever+0x90/0x138 [452744.125324] [452744.125325] Kernel panic - not syncing: Fatal exception in interrupt Note that bh_lock_sock() is not serializing the tasklet context against process context, because the check for sock_owned_by_user() and corresponding handling is missing. Ideas for a future clean-up patch: A) Correct usage of bh_lock_sock() in tasklet context, as described in Re-enqueue, if needed. This may require adding return values to the tasklet functions and thus changes to all users of iucv. B) Change iucv tasklet into worker and use only lock_sock() in af_iucv. A possible use-after-free vulnerability was found in the Linux kernel in iucv_sock_close(). This issue may lead to a crash or memory corruption. • https://git.kernel.org/stable/c/7d316b9453523498246e9e19a659c423d4c5081e https://git.kernel.org/stable/c/84f40b46787ecb67c7ad08a5bb1376141fa10c01 https://git.kernel.org/stable/c/37652fbef9809411cea55ea5fa1a170e299efcd0 https://git.kernel.org/stable/c/c65f72eec60a34ace031426e04e9aff8e5f04895 https://git.kernel.org/stable/c/ac758e1f663fe9bc64f6b47212a2aa18697524f5 https://git.kernel.org/stable/c/8b424c9e44111c5a76f41c6b741f8d4c4179d876 https://git.kernel.org/stable/c/01437282fd3904810603f3dc98d2cac6b8b6fc84 https://git.kernel.org/stable/c/69620522c48ce8215e5eb55ffbab8cafe • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-42267 – riscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error()
https://notcve.org/view.php?id=CVE-2024-42267
In the Linux kernel, the following vulnerability has been resolved: riscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error() Handle VM_FAULT_SIGSEGV in the page fault path so that we correctly kill the process and we don't BUG() the kernel. • https://git.kernel.org/stable/c/07037db5d479f90377c998259a4f9a469c404edf https://git.kernel.org/stable/c/59be4a167782d68e21068a761b90b01fadc09146 https://git.kernel.org/stable/c/20dbdebc5580cd472a310d56a6e252275ee4c864 https://git.kernel.org/stable/c/d7ccf2ca772bfe33e2c53ef80fa20d2d87eb6144 https://git.kernel.org/stable/c/917f598209f3f5e4ab175d5079d8aeb523e58b1f https://git.kernel.org/stable/c/d4e7db757e2d7f4c407a007e92c98477eab215d2 https://git.kernel.org/stable/c/0c710050c47d45eb77b28c271cddefc5c785cb40 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42265 – protect the fetch of ->fd[fd] in do_dup2() from mispredictions
https://notcve.org/view.php?id=CVE-2024-42265
In the Linux kernel, the following vulnerability has been resolved: protect the fetch of ->fd[fd] in do_dup2() from mispredictions both callers have verified that fd is not greater than ->max_fds; however, misprediction might end up with tofree = fdt->fd[fd]; being speculatively executed. That's wrong for the same reasons why it's wrong in close_fd()/file_close_fd_locked(); the same solution applies - array_index_nospec(fd, fdt->max_fds) could differ from fd only in case of speculative execution on mispredicted path. • https://git.kernel.org/stable/c/ed42e8ff509d2a61c6642d1825032072dab79f26 https://git.kernel.org/stable/c/41a6c31df77bd8e050136b0a200b537da9e1084a https://git.kernel.org/stable/c/08775b3d6ed117cf4518754ec7300ee42b6a5368 https://git.kernel.org/stable/c/3f480493550b6a23d3a65d095d6569d4a7f56a0f https://git.kernel.org/stable/c/5db999fff545b924b24c9afd368ef5c17279b176 https://git.kernel.org/stable/c/da72e783afd27d9f487836b2e6738146c0edd149 https://git.kernel.org/stable/c/1171ceccabfd596ca370c5d2cbb47d110c3f2fe1 https://git.kernel.org/stable/c/8aa37bde1a7b645816cda8b80df4753ec • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •