CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49926 – rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb()
https://notcve.org/view.php?id=CVE-2024-49926
In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: <TASK> ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? • https://git.kernel.org/stable/c/b3b2431ed27f4ebc28e26cdf005c1de42dc60bdf https://git.kernel.org/stable/c/3104bddc666ff64b90491868bbc4c7ebdd90aedf https://git.kernel.org/stable/c/05095271a4fb0f6497121a057f9a2edf386d5d96 https://git.kernel.org/stable/c/fd70e9f1d85f5323096ad313ba73f5fe3d15ea41 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49925 – fbdev: efifb: Register sysfs groups through driver core
https://notcve.org/view.php?id=CVE-2024-49925
In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed. • https://git.kernel.org/stable/c/36bfefb6baaa8e46de44f4fd919ce4347337620f https://git.kernel.org/stable/c/872cd2d029d2c970a8a1eea88b48dab2b3f2e93a https://git.kernel.org/stable/c/4684d69b9670a83992189f6271dc0fcdec4ed0d7 https://git.kernel.org/stable/c/95cdd538e0e5677efbdf8aade04ec098ab98f457 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-49924 – fbdev: pxafb: Fix possible use after free in pxafb_task()
https://notcve.org/view.php?id=CVE-2024-49924
In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime. • https://git.kernel.org/stable/c/e657fa2df4429f3805a9b3e47fb1a4a1b02a72bd https://git.kernel.org/stable/c/6d0a07f68b66269e167def6c0b90a219cd3e7473 https://git.kernel.org/stable/c/e6897e299f57b103e999e62010b88e363b3eebae https://git.kernel.org/stable/c/4cda484e584be34d55ee17436ebf7ad11922b97a https://git.kernel.org/stable/c/3c0d416eb4bef705f699213cee94bf54b6acdacd https://git.kernel.org/stable/c/fdda354f60a576d52dcf90351254714681df4370 https://git.kernel.org/stable/c/aaadc0cb05c999ccd8898a03298b7e5c31509b08 https://git.kernel.org/stable/c/a3a855764dbacbdb1cc51e15dc588f2d2 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49923 – drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags
https://notcve.org/view.php?id=CVE-2024-49923
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] "dcn20_validate_apply_pipe_split_flags" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity. • https://git.kernel.org/stable/c/85aa996ecfaa95d1e922867390502d23ce21b905 https://git.kernel.org/stable/c/9a05270869f40c89f8d184fe2d37cb86e0d7e5f5 https://git.kernel.org/stable/c/5559598742fb4538e4c51c48ef70563c49c2af23 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49922 – drm/amd/display: Check null pointers before using them
https://notcve.org/view.php?id=CVE-2024-49922
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity. • https://git.kernel.org/stable/c/65e1d2c291553ef3f433a0b7109cc3002a5f40ae https://git.kernel.org/stable/c/5e9386baa3033c369564d55de4bab62423e8a1d3 https://git.kernel.org/stable/c/1ff12bcd7deaeed25efb5120433c6a45dd5504a8 •