CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-43902 – drm/amd/display: Add null checker before passing variables
https://notcve.org/view.php?id=CVE-2024-43902
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null checker before passing variables Checks null pointer before passing variables to functions. This fixes 3 NULL_RETURNS issues reported by Coverity. • https://git.kernel.org/stable/c/d0b8b23b9c2ebec693a36fea518d8f13493ad655 https://git.kernel.org/stable/c/83c7f509ef087041604e9572938f82e18b724c9d https://git.kernel.org/stable/c/4cc2a94d96caeb3c975acdae7351c2f997c32175 https://git.kernel.org/stable/c/1686675405d07f35eae7ff3d13a530034b899df2 https://git.kernel.org/stable/c/8092aa3ab8f7b737a34b71f91492c676a843043a •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43901 – drm/amd/display: Fix NULL pointer dereference for DTN log in DCN401
https://notcve.org/view.php?id=CVE-2024-43901
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL pointer dereference for DTN log in DCN401 When users run the command: cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log The following NULL pointer dereference happens: [ +0.000003] BUG: kernel NULL pointer dereference, address: NULL [ +0.000005] #PF: supervisor instruction fetch in kernel mode [ +0.000002] #PF: error_code(0x0010) - not-present page [ +0.000002] PGD 0 P4D 0 [ +0.000004] Oops: 0010 [#1] PREEMPT SMP NOPTI [ +0.000003] RIP: 0010:0x0 [ +0.000008] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [...] [ +0.000002] PKRU: 55555554 [ +0.000002] Call Trace: [ +0.000002] <TASK> [ +0.000003] ? show_regs+0x65/0x70 [ +0.000006] ? __die+0x24/0x70 [ +0.000004] ? page_fault_oops+0x160/0x470 [ +0.000006] ? do_user_addr_fault+0x2b5/0x690 [ +0.000003] ? • https://git.kernel.org/stable/c/1e68b7ce6bc6073579fe8713ec6b85aa9cd2e351 https://git.kernel.org/stable/c/5af757124792817f8eb1bd0c80ad60fab519586b •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-43900 – media: xc2028: avoid use-after-free in load_firmware_cb()
https://notcve.org/view.php?id=CVE-2024-43900
In the Linux kernel, the following vulnerability has been resolved: media: xc2028: avoid use-after-free in load_firmware_cb() syzkaller reported use-after-free in load_firmware_cb() [1]. The reason is because the module allocated a struct tuner in tuner_probe(), and then the module initialization failed, the struct tuner was released. A worker which created during module initialization accesses this struct tuner later, it caused use-after-free. The process is as follows: task-6504 worker_thread tuner_probe <= alloc dvb_frontend [2] ... request_firmware_nowait <= create a worker ... tuner_remove <= free dvb_frontend ... request_firmware_work_func <= the firmware is ready load_firmware_cb <= but now the dvb_frontend has been freed To fix the issue, check the dvd_frontend in load_firmware_cb(), if it is null, report a warning and just return. [1]: ================================================================== BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0 Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504 Call trace: load_firmware_cb+0x1310/0x17a0 request_firmware_work_func+0x128/0x220 process_one_work+0x770/0x1824 worker_thread+0x488/0xea0 kthread+0x300/0x430 ret_from_fork+0x10/0x20 Allocated by task 6504: kzalloc tuner_probe+0xb0/0x1430 i2c_device_probe+0x92c/0xaf0 really_probe+0x678/0xcd0 driver_probe_device+0x280/0x370 __device_attach_driver+0x220/0x330 bus_for_each_drv+0x134/0x1c0 __device_attach+0x1f4/0x410 device_initial_probe+0x20/0x30 bus_probe_device+0x184/0x200 device_add+0x924/0x12c0 device_register+0x24/0x30 i2c_new_device+0x4e0/0xc44 v4l2_i2c_new_subdev_board+0xbc/0x290 v4l2_i2c_new_subdev+0xc8/0x104 em28xx_v4l2_init+0x1dd0/0x3770 Freed by task 6504: kfree+0x238/0x4e4 tuner_remove+0x144/0x1c0 i2c_device_remove+0xc8/0x290 __device_release_driver+0x314/0x5fc device_release_driver+0x30/0x44 bus_remove_device+0x244/0x490 device_del+0x350/0x900 device_unregister+0x28/0xd0 i2c_unregister_device+0x174/0x1d0 v4l2_device_unregister+0x224/0x380 em28xx_v4l2_init+0x1d90/0x3770 The buggy address belongs to the object at ffff8000d7ca2000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 776 bytes inside of 2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800) The buggy address belongs to the page: page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0 flags: 0x7ff800000000100(slab) raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [2] Actually, it is allocated for struct tuner, and dvb_frontend is inside. • https://git.kernel.org/stable/c/ef517bdfc01818419f7bd426969a0c86b14f3e0e https://git.kernel.org/stable/c/850304152d367f104d21c77cfbcc05806504218b https://git.kernel.org/stable/c/208deb6d8c3cb8c3acb1f41eb31cf68ea08726d5 https://git.kernel.org/stable/c/68594cec291ff9523b9feb3f43fd853dcddd1f60 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43899 – drm/amd/display: Fix null pointer deref in dcn20_resource.c
https://notcve.org/view.php?id=CVE-2024-43899
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix null pointer deref in dcn20_resource.c Fixes a hang thats triggered when MPV is run on a DCN401 dGPU: mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=all and then enabling fullscreen playback (double click on the video) The following calltrace will be seen: [ 181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 181.843997] #PF: supervisor instruction fetch in kernel mode [ 181.844003] #PF: error_code(0x0010) - not-present page [ 181.844009] PGD 0 P4D 0 [ 181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI [ 181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018 [ 181.844044] RIP: 0010:0x0 [ 181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246 [ 181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004 [ 181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400 [ 181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c [ 181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8 [ 181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005 [ 181.844121] FS: 00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000 [ 181.844128] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0 [ 181.844141] Call Trace: [ 181.844146] <TASK> [ 181.844153] ? show_regs+0x6d/0x80 [ 181.844167] ? __die+0x24/0x80 [ 181.844179] ? page_fault_oops+0x99/0x1b0 [ 181.844192] ? do_user_addr_fault+0x31d/0x6b0 [ 181.844204] ? • https://git.kernel.org/stable/c/974fccd61758599a9716c4b909d9226749efe37e https://git.kernel.org/stable/c/ecbf60782662f0a388493685b85a645a0ba1613c •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-43897 – net: drop bad gso csum_start and offset in virtio_net_hdr
https://notcve.org/view.php?id=CVE-2024-43897
In the Linux kernel, the following vulnerability has been resolved: net: drop bad gso csum_start and offset in virtio_net_hdr Tighten csum_start and csum_offset checks in virtio_net_hdr_to_skb for GSO packets. The function already checks that a checksum requested with VIRTIO_NET_HDR_F_NEEDS_CSUM is in skb linear. But for GSO packets this might not hold for segs after segmentation. Syzkaller demonstrated to reach this warning in skb_checksum_help offset = skb_checksum_start_offset(skb); ret = -EINVAL; if (WARN_ON_ONCE(offset >= skb_headlen(skb))) By injecting a TSO packet: WARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0 ip_do_fragment+0x209/0x1b20 net/ipv4/ip_output.c:774 ip_finish_output_gso net/ipv4/ip_output.c:279 [inline] __ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301 iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x2296/0x2c70 net/ipv4/ip_tunnel.c:813 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661 __netdev_start_xmit include/linux/netdevice.h:4850 [inline] netdev_start_xmit include/linux/netdevice.h:4864 [inline] xmit_one net/core/dev.c:3595 [inline] dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611 __dev_queue_xmit+0x1b97/0x3c90 net/core/dev.c:4261 packet_snd net/packet/af_packet.c:3073 [inline] The geometry of the bad input packet at tcp_gso_segment: [ 52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0 [ 52.003050][ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244 [ 52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(size=1552 type=3 segs=0)) [ 52.003050][ T8403] csum(0x60000c7 start=199 offset=1536 ip_summed=3 complete_sw=0 valid=0 level=0) Mitigate with stricter input validation. csum_offset: for GSO packets, deduce the correct value from gso_type. This is already done for USO. Extend it to TSO. Let UFO be: udp[46]_ufo_fragment ignores these fields and always computes the checksum in software. csum_start: finding the real offset requires parsing to the transport header. Do not add a parser, use existing segmentation parsing. • https://git.kernel.org/stable/c/27874ca77bd2b05a3779c7b3a5c75d8dd7f0b40f https://git.kernel.org/stable/c/5b1997487a3f3373b0f580c8a20b56c1b64b0775 https://git.kernel.org/stable/c/90d41ebe0cd4635f6410471efc1dd71b33e894cf https://git.kernel.org/stable/c/e9164903b8b303c34723177b02fe91e49e3c4cd7 https://git.kernel.org/stable/c/413e785a89f8bde0d4156a54b8ac2fa003c06756 https://git.kernel.org/stable/c/f01c5e335fbb7fb612d40f14a3c02e2612a43d3b https://git.kernel.org/stable/c/6772c4868a8e7ad5305957cdb834ce881793acb7 https://git.kernel.org/stable/c/2edbb3e8838c672cd7e247e47989df9d0 •