CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-56746 – fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()
https://notcve.org/view.php?id=CVE-2024-56746
In the Linux kernel, the following vulnerability has been resolved: fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem() When information such as info->screen_base is not ready, calling sh7760fb_free_mem() does not release memory correctly. Call dma_free_coherent() instead. • https://git.kernel.org/stable/c/4a25e41831ee851c1365d8b41decc22493b18e6d https://git.kernel.org/stable/c/0d3fb3b3e9d66f7b6346e3b90bc0ff48683539ce https://git.kernel.org/stable/c/d48cbfa90dce506030151915fa3346d67f964af4 https://git.kernel.org/stable/c/29216bb390e36daeebef66abaa02d9751330252b https://git.kernel.org/stable/c/f4fbd70e15fafe36a7583954ce189aaf5536aeec https://git.kernel.org/stable/c/40f4326ed05a3b3537556ff2a844958b9e779a98 https://git.kernel.org/stable/c/3dd9df8e5f34c6fc4217a7498c1fb3c352d4afc2 https://git.kernel.org/stable/c/d10cd53e5a7fb3b7c6f83d4d9a5ea1d97 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56741 – apparmor: test: Fix memory leak for aa_unpack_strdup()
https://notcve.org/view.php?id=CVE-2024-56741
In the Linux kernel, the following vulnerability has been resolved: apparmor: test: Fix memory leak for aa_unpack_strdup() The string allocated by kmemdup() in aa_unpack_strdup() is not freed and cause following memory leaks, free them to fix it. unreferenced object 0xffffff80c6af8a50 (size 8): comm "kunit_try_catch", pid 225, jiffies 4294894407 hex dump (first 8 bytes): 74 65 73 74 69 6e 67 00 testing. backtrace (crc 5eab668b): [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 [<000000006e6c7776>] __kmalloc_node_track_caller_noprof+0x300/0x3e0 [<000000006870467c>] kmemdup_noprof+0x34/0x60 [<000000001176bb03>] aa_unpack_strdup+0xd0/0x18c [<000000008ecde918>] policy_unpack_test_unpack_strdup_with_null_name+0xf8/0x3ec [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec [<00000000adf936cf>] kthread+0x2e8/0x374 [<0000000041bb1628>] ret_from_fork+0x10/0x20 unreferenced object 0xffffff80c2a29090 (size 8): comm "kunit_try_catch", pid 227, jiffies 4294894409 hex dump (first 8 bytes): 74 65 73 74 69 6e 67 00 testing. backtrace (crc 5eab668b): [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 [<000000006e6c7776>] __kmalloc_node_track_caller_noprof+0x300/0x3e0 [<000000006870467c>] kmemdup_noprof+0x34/0x60 [<000000001176bb03>] aa_unpack_strdup+0xd0/0x18c [<0000000046a45c1a>] policy_unpack_test_unpack_strdup_with_name+0xd0/0x3c4 [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec [<00000000adf936cf>] kthread+0x2e8/0x374 [<0000000041bb1628>] ret_from_fork+0x10/0x20 • https://git.kernel.org/stable/c/4d944bcd4e731ab7bfe8d01a7041ea0ebdc090f1 https://git.kernel.org/stable/c/f856246ff6da25c4f8fdd73a9c875e878b085e9f https://git.kernel.org/stable/c/5354599855a9b5568e05ce686119ee3ff8b19bd5 https://git.kernel.org/stable/c/89265f88701e54dde255ddf862093baeca57548c https://git.kernel.org/stable/c/2a9b68f2dc6812bd1b8880b5c00e60203d6f61f6 https://git.kernel.org/stable/c/59a149e7c38e7b76616c8b333fc6aa5b6fb2293c https://git.kernel.org/stable/c/d62ee5739a66644b0e7f11e657d562458cdcdea3 https://git.kernel.org/stable/c/7290f59231910ccba427d441a6e8b8c6f •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-56739 – rtc: check if __rtc_read_time was successful in rtc_timer_do_work()
https://notcve.org/view.php?id=CVE-2024-56739
In the Linux kernel, the following vulnerability has been resolved: rtc: check if __rtc_read_time was successful in rtc_timer_do_work() If the __rtc_read_time call fails,, the struct rtc_time tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware. When calling rtc_tm_to_ktime later, the result may be a very large value (possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue, they will continually expire, may causing kernel softlockup. • https://git.kernel.org/stable/c/6610e0893b8bc6f59b14fed7f089c5997f035f88 https://git.kernel.org/stable/c/39ad0a1ae17b54509cd9e93dcd8cec16e7c12d3f https://git.kernel.org/stable/c/44b3257ff705d63d5f00ef8ed314a0eeb7ec37f2 https://git.kernel.org/stable/c/0d68e8514d9040108ff7d1b37ca71096674b6efe https://git.kernel.org/stable/c/246f621d363988e7040f4546d20203dc713fa3e1 https://git.kernel.org/stable/c/fde56535505dde3336df438e949ef4742b6d6d6e https://git.kernel.org/stable/c/dd4b1cbcc916fad5d10c2662b62def9f05e453d4 https://git.kernel.org/stable/c/a1f0b4af90cc18b10261ecde56c6a56b2 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56728 – octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c
https://notcve.org/view.php?id=CVE-2024-56728
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c Add error pointer check after calling otx2_mbox_get_rsp(). • https://git.kernel.org/stable/c/75f36270990c7875c0091afb961ca37f52b6bc55 https://git.kernel.org/stable/c/5ff9de1f2712cbca53da2e37d831eea7ffcb43b6 https://git.kernel.org/stable/c/55c41b97001a09bb490ffa2e667e251d75d15ab1 https://git.kernel.org/stable/c/05a6ce174c0c724e5914e1e5efd826bab8f382b4 https://git.kernel.org/stable/c/c0f64fd73b60aee85f88c270c9d714ead27a7b7a https://git.kernel.org/stable/c/6cda142cee032b8fe65ee11f78721721c3988feb https://git.kernel.org/stable/c/2db2194727b1f49a5096c1c3981adef1b7638733 https://git.kernel.org/stable/c/e26f8eac6bb20b20fdb8f7dc695711ebc •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-56724 – mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device
https://notcve.org/view.php?id=CVE-2024-56724
In the Linux kernel, the following vulnerability has been resolved: mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. • https://git.kernel.org/stable/c/957ae5098185e763b5c06be6c3b4b6e98c048712 https://git.kernel.org/stable/c/b7c7c400de85d915e0da7c2c363553a801c47349 https://git.kernel.org/stable/c/c472b55cc0bc3df805db6a14f50a084884cf18ee https://git.kernel.org/stable/c/da498e02c92e6d82df8001438dd583b90c570815 https://git.kernel.org/stable/c/56acf415772ee7e10e448b371f52b249aa2d0f7b https://git.kernel.org/stable/c/1b734ad0e33648c3988c6a37c2ac16c2d63eda06 https://git.kernel.org/stable/c/2310f5336f32eac9ada2d59b965d578efe25c4bf https://git.kernel.org/stable/c/5bc6d0da4a32fe34a9960de577e0b7de3 •