Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

13 participants
7966 discussions

[PATCH v3] dma-buf: Fix silent overflow for phys vec to sgt

by David Hu

In case MMIO size is bigger than 4G and peer2peer DMA goes through host bridge, we trigger a code path that assigns the total linked IOVA (which is greater than 4G) to mapped_len. Previously, `mapped_len` was declared as 32-bit `unsigned int`. When accumulating `size_t` lengths, this leads to a silent wrap-around. This truncation causes truncated lengths to be passed to functions like `fill_sg_entry()`. Fix this by changing `mapped_len` to `size_t` (64-bit). While at it, fix similar potential overflow issues in `calc_sg_nents` by using `size_t` for `nents` and checking against `UINT_MAX` and using `unsigned int` for the loop iterator in `fill_sg_entry` to match. Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine") Cc: stable(a)vger.kernel.org Cc: iommu(a)lists.linux.dev Reviewed-by: Pranjal Shrivastava <praan(a)google.com> Signed-off-by: David Hu <xuehaohu(a)google.com> --- Changes in v3: - Removed leftover sentence fragment from the commit message. - Kept `nents = 0` initialization (previously stated as removed in the v2 changelog) as it is strictly required for the `+=` accumulation loop in `calc_sg_nents()`. Changes in v2: - Fixed 'IVOA' -> 'IOVA' typo and expanded commit message (Claude Bot). - Added Reverse Xmas tree formatting (Pranjal). - Folded in extra bounds checking for calc_sg_nents() (Pranjal). - Folded in type consistency fix for fill_sg_entry() (Pranjal). drivers/dma-buf/dma-buf-mapping.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-buf-mapping.c index 794acff2546a..5bc769fc42ea 100644 --- a/drivers/dma-buf/dma-buf-mapping.c +++ b/drivers/dma-buf/dma-buf-mapping.c @@ -10,7 +10,7 @@ static struct scatterlist *fill_sg_entry(struct scatterlist *sgl, size_t length, dma_addr_t addr) { unsigned int len, nents; - int i; + unsigned int i; nents = DIV_ROUND_UP(length, UINT_MAX); for (i = 0; i < nents; i++) { @@ -36,7 +36,7 @@ static unsigned int calc_sg_nents(struct dma_iova_state *state, struct phys_vec *phys_vec, size_t nr_ranges, size_t size) { - unsigned int nents = 0; + size_t nents = 0; size_t i; if (!state || !dma_use_iova(state)) { @@ -51,6 +51,9 @@ static unsigned int calc_sg_nents(struct dma_iova_state *state, nents = DIV_ROUND_UP(size, UINT_MAX); } + if (nents > UINT_MAX) + return 0; + return nents; } @@ -95,9 +98,10 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, size_t nr_ranges, size_t size, enum dma_data_direction dir) { - unsigned int nents, mapped_len = 0; struct dma_buf_dma *dma; struct scatterlist *sgl; + size_t mapped_len = 0; + unsigned int nents; dma_addr_t addr; size_t i; int ret; -- 2.54.0.794.g4f17f83d09-goog

2 months, 1 week

[PATCH] dma-buf: fix UAF in dma_buf_fd() tracepoint

by David Carlier

Once FD_ADD() returns, the fd is live in the file descriptor table and a thread sharing that table can close() it before DMA_BUF_TRACE() runs. The close drops the last reference, __fput() frees the dma_buf, and the tracepoint then dereferences dmabuf to take dmabuf->name_lock -- slab-use-after-free. Split FD_ADD() back into get_unused_fd_flags() + fd_install() and emit the tracepoint between them. While the fdtable slot is reserved with a NULL file pointer, a racing close() returns -EBADF without entering __fput(), so the dma_buf stays alive across the trace. Same approach as commit 2d76319c4cbb ("dma-buf: fix UAF in dma_buf_put() tracepoint"). This undoes the FD_ADD() conversion done in commit 34dfce523c90 ("dma: convert dma_buf_fd() to FD_ADD()"); FD_ADD() has no place to hook the tracepoint safely. Reported-by: syzbot+7f4987d0afb97dd090cb(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=7f4987d0afb97dd090cb Fixes: 281a22631423 ("dma-buf: add some tracepoints to debug.") Cc: stable(a)vger.kernel.org # 7.0.x Signed-off-by: David Carlier <devnexen(a)gmail.com> --- drivers/dma-buf/dma-buf.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 71f37544a5c6..d504c636dc29 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -792,9 +792,13 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags) if (!dmabuf || !dmabuf->file) return -EINVAL; - fd = FD_ADD(flags, dmabuf->file); + fd = get_unused_fd_flags(flags); + if (fd < 0) + return fd; + DMA_BUF_TRACE(trace_dma_buf_fd, dmabuf, fd); + fd_install(fd, dmabuf->file); return fd; } EXPORT_SYMBOL_NS_GPL(dma_buf_fd, "DMA_BUF"); -- 2.53.0

2 months, 1 week

Whatsapp: +33 754.090.961, How get location in Abou Dhabi, UAE read full story .

by brekkea78＠gmail.com

Whatsapp: +33 754.090.961, How i buy Dispensary in Dubai, read full story . Order the free ebook on Whatsapp: +33 754.090.961 of how i buy 70mg lyrica in #jeddah. For those wondering where to buy #THC vapes in UAE, it’s important to find a provider that values purity, potency, and customer confidentiality go on: https://uaetherapist.com/ the online drop. I like spent my holiday In United Arab Emirates , the streets are amazing most in the night one day inside a uber the driver who take me from #Al_wahda ask me if he can play music i told him ‘’ YOU ARE WELCOME BRO ’’ then i heard 50cent in window shopper i get a small smile in the corner of my face. At that moment i don’t know why, suddenly i started to think about Coffee Sh0p how i can roll a split , but DAMMN MAN YOU ARE CLEAN OVER 3 YEARS!! You are in Dubai, is like Bahrain, as Saudi , like Oman it’s impossible to get a coffee shop here anyway you risk to go through huge problem with arabic country law !! I was saw my pregnant girlfiend who are waiting me at Charjah, my new work who permit me to travel as i want with my family all the life i have for , no man stay focus on your job in MANAMA ... FOLLOW HAPPENED STORY ON Whatsapp: +33 754.090.961 and you will know where i bought THC gummies in Dubai. Contacts: Telegram: Go0dTherapist Gmail: uaetherapist(a)gmail.com Signal: addsilkroad.47 Whatsapp: https://whatsapp.com/channel/0029VbCcd6PLCoX7L05OeX3a Tik Tok: https://vm.tiktok.com/ZS9R3Cn5sdvLu-YwLbv/ https://uaetherapist.com/how-to-order/ https://uaetherapist.com/shop/ https://uaetherapist.com/faqs/ https://uaetherapist.com/policies/ https://uaetherapist.com/contact/ #uaetherapist.com #uaetherapistdotcom #dubaidispensary #uaemedicated

2 months, 1 week

Whatsapp: +33 754.090.961, How i get location in Abou Dabi, UAE.read full story .

by brekkea78＠gmail.com

2 months, 1 week

Unleash Your Inner Blade: A Guide to the Satisfying World of Slice Master

by profound.cheetah.kect＠hidingmail.net

Ever found yourself in a moment of boredom, scrolling aimlessly, and wishing for something simple yet utterly satisfying to engage your mind? Look no further than the delightful genre of slicing games, and specifically, the incredibly addictive Slice Master. These games offer a unique blend of precision, timing, and visual gratification, making them a perfect pick-up-and-play experience for anyone looking to unwind. https://slicemasterfree.com What is Slice Master, and Why Should You Try It? At its core, Slice Master is a game about, well, slicing! Imagine a canvas filled with various shapes and objects, and your goal is to meticulously cut them into smaller, designated pieces using a virtual blade. It sounds deceptively simple, but the genius lies in its execution. The game's intuitive controls and satisfying physics make each slice feel impactful, and the challenge gradually increases, keeping you hooked. Think of it as a digital meditation, where the act of carefully dissecting objects becomes a strangely calming and rewarding experience. The visual feedback of cleanly cut shapes, often accompanied by satisfying sound effects, creates a positive loop that encourages you to keep playing. Getting Started: A Glimpse into the Gameplay Playing Slice Master is incredibly straightforward, making it accessible to gamers of all ages and skill levels. Here's a basic rundown of what you can expect: The Objective: Each level presents you with a set of objects. Your goal is to slice them into a specific number of smaller pieces, often along indicated lines or into particular shapes. The Blade: You control a virtual blade, usually by dragging your finger or mouse across the screen. The key is to make smooth, precise movements to achieve clean cuts. Precision is Key: Hitting the target lines perfectly often yields higher scores or unlocks bonus points. Messy cuts might mean restarting a section or losing points. Varying Challenges: As you progress, you'll encounter different materials that require more careful slicing, moving objects, or even time limits, adding layers of complexity to the core mechanic. Tips for Becoming a Slice Master While the game is easy to pick up, mastering it requires a bit of finesse. Here are a few friendly tips to enhance your slicing skills: Practice Makes Perfect: Don't be discouraged by imperfect cuts at first. The more you play, the better your hand-eye coordination and precision will become. Observe the Target: Before you make your first cut, take a moment to analyze the object and the desired outcome. Visualize your cut path. Smooth and Steady Wins the Race: Avoid jerky movements. A slow, deliberate drag of your blade is often more effective than a quick, frantic swipe. Utilize the Edges: Sometimes, using the edges of the object as a guide for your cuts can help you achieve straighter and more accurate slices. Don't Be Afraid to Restart: If a cut goes horribly wrong, many levels allow you to restart that particular segment. It's better to restart and achieve a perfect score than to muddle through with a subpar cut. Conclusion: A Simple Joy Slice Master and similar slicing games offer a delightful escape from the hustle and bustle of everyday life. Their uncomplicated yet engaging gameplay provides a sense of accomplishment and a unique form of digital satisfaction. Whether you have five minutes to spare or an hour to unwind, diving into the world of precise cuts and satisfying visuals is a worthwhile endeavor. So, grab your virtual blade and prepare to experience the quiet joy of becoming a true Slice Master!

2 months, 1 week

[PATCH v2] dma-buf: set SB_I_NOEXEC and SB_I_NODEV on the pseudo filesystem

by John Hubbard

The dma-buf pseudo filesystem dispenses S_ANON_INODE inodes via alloc_anon_inode() but never sets SB_I_NOEXEC on its superblock. Since commit 1e7ab6f67824 ("anon_inode: rework assertions") in 6.17, path_noexec() warns on exactly that combination, so an mmap() on any dma-buf fd trips the warning: WARNING: CPU: 11 PID: 121813 at fs/exec.c:118 path_noexec+0x47/0x50 do_mmap+0x2b5/0x680 vm_mmap_pgoff+0x129/0x210 ksys_mmap_pgoff+0x177/0x240 __x64_sys_mmap+0x33/0x70 dma-bufs have no business being executable, which is the invariant that the new assertion is enforcing. Set SB_I_NOEXEC. Also set SB_I_NODEV, since the pseudo filesystem creates no device nodes. Reproducer on a CONFIG_DEBUG_VFS=y kernel: make -C tools/testing/selftests/dmabuf-heaps sudo ./tools/testing/selftests/dmabuf-heaps/dmabuf-heap -t system The selftest allocates from /dev/dma_heap/system and mmaps the returned fd, which trips the warning without this patch. Fixes: 1e7ab6f67824 ("anon_inode: rework assertions") Cc: stable(a)vger.kernel.org Reviewed-by: Christian Brauner (Amutable) <brauner(a)kernel.org> Signed-off-by: John Hubbard <jhubbard(a)nvidia.com> --- Changes since v1: * Also set SB_I_NODEV (suggested by Christian Brauner). * Added Christian Brauner's Reviewed-by tag (thanks!) drivers/dma-buf/dma-buf.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 71f37544a5c6..ea1ddd4293b2 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -216,6 +216,8 @@ static int dma_buf_fs_init_context(struct fs_context *fc) if (!ctx) return -ENOMEM; ctx->dops = &dma_buf_dentry_ops; + fc->s_iflags |= SB_I_NOEXEC; + fc->s_iflags |= SB_I_NODEV; return 0; } base-commit: 6779b50faa562e6cca1aa6a4649a4d764c6c7e28 -- 2.54.0

2 months, 1 week

[PATCH v2] dma-buf: Fix silent overflow for phys vec to sgt

by David Hu

In case MMIO size is bigger than 4G and peer2peer DMA goes through host bridge, we trigger a code path that assigns the total linked IOVA (which is greater than 4G) to mapped_len. Previously, `mapped_len` was declared as 32-bit `unsigned int`. When accumulating `size_t` lengths, this leads to a silent wrap-around. This truncation causes truncated lengths to be passed to functions like `fill_sg_entry()`. Fix this by changing `mapped_len` to `size_t` (64-bit). While at it, fix similar potential overflow issues in `calc_sg_nents` by using `size_t` for `nents` and checking against `UINT_MAX` and using `unsigned int` for the loop iterator in `fill_sg_entry` to match. to mapped_len, and leading to a silent overflow Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine") Cc: stable(a)vger.kernel.org Cc: iommu(a)lists.linux.dev Reviewed-by: Pranjal Shrivastava <praan(a)google.com> Signed-off-by: David Hu <xuehaohu(a)google.com> --- Changes in v2: Fixed 'IVOA' -> 'IOVA' typo and expanded commit message (Claude Bot). Added Reverse Xmas tree formatting (Pranjal). Folded in extra bounds checking for calc_sg_nents() (Pranjal). Folded in type consistency fix for fill_sg_entry() (Pranjal). Droped unnecessary `nents = 0` initialization (Claude Bot). drivers/dma-buf/dma-buf-mapping.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-buf-mapping.c index 794acff2546a..5bc769fc42ea 100644 --- a/drivers/dma-buf/dma-buf-mapping.c +++ b/drivers/dma-buf/dma-buf-mapping.c @@ -10,7 +10,7 @@ static struct scatterlist *fill_sg_entry(struct scatterlist *sgl, size_t length, dma_addr_t addr) { unsigned int len, nents; - int i; + unsigned int i; nents = DIV_ROUND_UP(length, UINT_MAX); for (i = 0; i < nents; i++) { @@ -36,7 +36,7 @@ static unsigned int calc_sg_nents(struct dma_iova_state *state, struct phys_vec *phys_vec, size_t nr_ranges, size_t size) { - unsigned int nents = 0; + size_t nents = 0; size_t i; if (!state || !dma_use_iova(state)) { @@ -51,6 +51,9 @@ static unsigned int calc_sg_nents(struct dma_iova_state *state, nents = DIV_ROUND_UP(size, UINT_MAX); } + if (nents > UINT_MAX) + return 0; + return nents; } @@ -95,9 +98,10 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, size_t nr_ranges, size_t size, enum dma_data_direction dir) { - unsigned int nents, mapped_len = 0; struct dma_buf_dma *dma; struct scatterlist *sgl; + size_t mapped_len = 0; + unsigned int nents; dma_addr_t addr; size_t i; int ret; -- 2.54.0.794.g4f17f83d09-goog

2 months, 1 week

[PATCH] dma-buf: Fix silent overflow for phys vec to sgt

by David Hu

In case MMIO size is bigger than 4G, and peer2peer dma goes through host bridge, we trigger the code path to assign total linked IVOA, greater than 4G to mapped_len, and leading to a silent overflow Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine") Signed-off-by: David Hu <xuehaohu(a)google.com> --- drivers/dma-buf/dma-buf-mapping.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-buf-mapping.c index 794acff2546a..658064140357 100644 --- a/drivers/dma-buf/dma-buf-mapping.c +++ b/drivers/dma-buf/dma-buf-mapping.c @@ -95,7 +95,8 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, size_t nr_ranges, size_t size, enum dma_data_direction dir) { - unsigned int nents, mapped_len = 0; + unsigned int nents = 0; + size_t mapped_len = 0; struct dma_buf_dma *dma; struct scatterlist *sgl; dma_addr_t addr; -- 2.54.0.563.g4f69b47b94-goog

2 months, 1 week

[PATCH v14 0/6] rust: drm: gem: shmem: Add sg_table() function

by Lyude Paul

(was previously Rust bindings for gem shmem) Most of this patch series has already been pushed upstream, this is just the second half of the patch series that has not been pushed yet + some additional changes which were required to implement changes requested by the mailing list. This patch series is originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/164580/ Branch with patches applied available here: https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem This patch series applies on top of drm-rust-next with the following dependencies applied: https://lkml.org/lkml/2026/5/26/1960 Lyude Paul (6): rust: faux: Allow retrieving a bound Device rust: gem: shmem: Fix Default implementation for ObjectConfig rust: drm: gem: s/device::Device/Device/ for shmem.rs drm/gem/shmem: Introduce __drm_gem_shmem_free_sgt_locked() rust: drm: gem/shmem: Add DmaResvGuard helper rust: drm: gem: Introduce shmem::Object::sg_table() drivers/gpu/drm/drm_gem_shmem_helper.c | 32 ++- include/drm/drm_gem_shmem_helper.h | 1 + rust/kernel/drm/gem/shmem.rs | 264 +++++++++++++++++++++++-- rust/kernel/faux.rs | 7 +- 4 files changed, 279 insertions(+), 25 deletions(-) base-commit: 2cf1840b0fa7637b6731fd554529f8d57ea34c04 prerequisite-patch-id: c8ade07eec6e9c9e875800b114137c459d362e4e prerequisite-patch-id: dc4f750bc885b867842587b994261f43602bc6a8 -- 2.54.0

2 months, 1 week

[PATCH] dma-buf: Move dma_resv_assert_held() after input validation

by lirongqing

From: Li RongQing <lirongqing(a)baidu.com> Move dma_resv_assert_held() after the validation of 'attach' and 'attach->dmabuf' to avoid a potential null pointer dereference if the function is ever called with invalid arguments. Signed-off-by: Li RongQing <lirongqing(a)baidu.com> --- drivers/dma-buf/dma-buf-mapping.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-buf-mapping.c index 794acff..e6ecd6c 100644 --- a/drivers/dma-buf/dma-buf-mapping.c +++ b/drivers/dma-buf/dma-buf-mapping.c @@ -102,12 +102,12 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, size_t i; int ret; - dma_resv_assert_held(attach->dmabuf->resv); - if (WARN_ON(!attach || !attach->dmabuf || !provider)) /* This function is supposed to work on MMIO memory only */ return ERR_PTR(-EINVAL); + dma_resv_assert_held(attach->dmabuf->resv); + dma = kzalloc_obj(*dma); if (!dma) return ERR_PTR(-ENOMEM); -- 2.9.4

2 months, 1 week

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig